
Introduction
I often get asked about setting up Adaptive Protection for Insider Risk Management. The process involves Insider Risk Management working in tandem with Conditional Access, both of which require the E5 level of licence. If you’re navigating this setup, you’re in the right place. In this blog, I’ll walk you through the steps, share some key definitions, and help you avoid common pitfalls (yes, including the dreaded false positives that can block users unnecessarily!). Recently, I delivered a "Zero to Hero session on Adaptive Protection with Insider Risk Management and Conditional Access" at a couple of user groups, where I covered these concepts in depth, and I wanted to share some of those key insights here, in a dedicated post.
Table of contents
Key definitions
Before diving into the setup, let's define some key concepts:
Insider Risk Management – A Microsoft Purview solution that helps organisations detect, investigate, and act on insider risks (e.g., data exfiltration, policy violations, or security breaches). It assigns risk levels to users based on detected activities.
Conditional Access – A feature in Microsoft Entra that applies security controls based on conditions such as user risk, device compliance, or location. It enforces policies dynamically to mitigate security risks.
Adaptive Protection – A mechanism that automatically adjusts enforcement actions based on a user’s risk level, applying stricter controls to users with higher insider risk scores.
How do these work together?
To effectively manage insider risk, you configure Insider Risk Management policies to monitor specific activities. When a user is flagged as risky, Conditional Access policies kick in, applying appropriate security measures. This dynamic approach ensures that controls are targeted and proportional, rather than blanket restrictions that frustrate users.
Risk levels vs. alert severity levels
One of the biggest sources of confusion is the difference between insider risk levels and alert severity levels:
Insider risk levels (elevated, moderate, minor) – Defined by admins based on user activity patterns (e.g., excessive data exfiltration). These levels determine how Adaptive Protection responds to a user’s behaviour.
Alert severity levels (low, medium, high) – Assigned based on specific insider risk policies detecting risky actions. These help analysts prioritise investigations.
Understanding this distinction is key to setting up a balanced and effective insider risk strategy.
The image below illustrates three different users, each representing varying levels of insider risk – minor, moderate, and high. Each user’s risk level is determined by their involvement in potentially risky activities, such as working on sensitive projects, resigning from the company, or engaging in data exfiltration. By evaluating these actions, organisations can tailor their response to each user’s risk level. For example, at the minor risk level, no additional controls might be necessary, allowing the user to continue working as normal. At the moderate risk level, more proactive measures are warranted, such as blocking BYOD (Bring Your Own Device) and USB usage, while also reminding the user of company policies and appropriate data handling procedures. Finally, at the high-risk level, the user’s access would be immediately revoked, pending a thorough review of the potential impact and damage.

Process flow: setting up adaptive protection
Here’s a step-by-step guide to configuring Adaptive Protection correctly:

*** *** ***

1. Configure global insider risk settings
Before doing anything else, fine-tune insider risk settings to align with your organisation’s security posture. Microsoft’s documentation won’t tell you this, but if you skip this step, you’ll likely end up drowning in false positives and accidentally blocking users who aren't actual threats.
As you can see in the below 3 screenshots (Figure 4, 5, and 6), nowhere is it mentioned that you should review the insider risk settings before creating or modifying your policies.



Navigate to: Purview Portal > Settings > Insider Risk Management Settings Overview
Before I dive into which settings should be modified, let me first provide an overview of the sub-settings available within the global insider risk settings. These settings allow you to customise how your organisation handles various types of insider risks, such as data exfiltration, malicious activity, or accidental data leakage. By adjusting these sub-settings, you can fine-tune the detection and response mechanisms to better align with your organisation's specific needs and risk tolerance. Understanding these options will give you a clearer picture of how to tailor your insider risk policies effectively.
Analytics Insider risk analytics allows you to assess potential insider threats without configuring specific policies. This evaluation helps identify high-risk areas and determine appropriate risk management strategies.
Data sharing Configure data sharing to:
Export insider risk management alerts to SIEM solutions using the Office 365 Management Activity API schema.
Share user risk levels with other security solutions.
Detection groups Create detection groups to customise built-in indicators for different user sets, reducing false positives.
Global exclusions Define global exclusions to prevent specific activities from being scored by insider risk management policies.
Inline alert customisation Modify risk management policies directly from the Alerts dashboard. Adjust alert thresholds or remove certain risk activities to minimise unnecessary alerts.
Intelligent detections Enhance risk scoring by:
Prioritising unusual download activity.
Controlling alert volume.
Importing and filtering Microsoft Defender for Endpoint alerts.
Defining unallowed and third-party domains.
Microsoft Teams Enable Teams support to allow compliance analysts to collaborate on risk management cases. Teams can be used to:
Review and coordinate case responses in private channels.
Securely store and share case files and evidence.
Track response activities by analysts and investigators.
Notifications Set up automatic email notifications for insider risk management role groups:
Notify when the first alert for a new policy is generated.
Send daily emails for new high-severity alerts.
Provide a weekly summary of unresolved policy warnings.
Policy indicators Each policy template includes specific indicators linked to risk activities. Since global indicators are disabled by default, select and configure relevant ones to tailor risk scoring.
Policy timeframes Define past and future review periods triggered by policy-related events and activities.
Power Automate flows Automate case and user management tasks with Microsoft Power Automate. Configure flows to:
Retrieve and share user, alert, and case details.
Automate actions like adding case notes or notifying stakeholders.
Priority physical assets Monitor user access to key locations (e.g., buildings, data centres) to detect suspicious activity, such as unauthorised access attempts or unusual working hours.
Priority user groups Assign higher scrutiny to users with greater access to sensitive data or a history of risky behaviour. This helps prioritise potential high-impact threats.
Privacy Choose to display either usernames or anonymised identifiers for alerts and case records.
***
I’m just going to run through some of the key settings you might want to tweak and customise based on your specific needs and how your organisation works. There might be another blog or video I’ll make to dive into these insider risk settings in more detail, showing you exactly how to set everything up. (Let me know in the comments or drop me a DM if you'd like a post dedicated to fine-tuning everything and going deeper into it.)
You’ll definitely want to have the Analytics turned on.

Make sure you’ve got “Share user risk details with other security solutions” enabled within the Data sharing options.

Detections > Domains – just wait for the page to load and make sure the “Free public domains” are showing up. You can also set up your own detection groups for domains here. These could be domains you don’t want your users communicating with, as well as those of your business partners, auditors, and so on. Right now, you’re just creating groups of domains, and later on you can decide what to do with them.

You have an option to add domains individually or import a list of them from a CSV file.

When it comes to sensitive info types (SITs), there are a bunch of out-of-the-box ones that can generate a lot of false positives. You might want to put them into a group and ignore them within your policies, or maybe group them to make it easier to add multiple SITs in actual insider risk management policies.

You can keep an eye on what built-in and custom classifiers get the most matches, by using the Information Protection explorers, like for example the Content explorer (classic).

As you can see in Figure 13, I’ve created several groups in my tenant – false positive generators, medical and diseases, credentials, GDPR stuff, and so on. These are just examples of SITs I commonly use, and also the ones I want to ignore in my policies, so I will be further configuring them under Global Exclusions > Sensitive Info Types.

Global Exclusions > Domains – this is where you can whitelist certain domains across all your policies. For example, if I’m going through an audit and the auditors ask for sensitive data via email or SharePoint, I want to temporarily make sure that the information I send them isn’t flagged, so I set a global exclusion for that.

Global Exclusions > Email Signature Attachments – I’d recommend enabling this one, it does exactly what it says on the tin.

You probably won’t need to configure this much, but it’s worth noting that some file paths are excluded by default.

Same goes for SITs – some individual SITs (like ICD-10 & ICD-9) are excluded by default, so just be aware of that.

The thing you may want to configure here are the global exclusions for SIT groups. You can see some examples in the screenshot below (Figure 18). I just don’t want any alerts logged for SITs I know don’t perform well and are always full of false positives, or maybe I don’t care about things like medical info or physical addresses being shared, depending on the industry I’m in. If you're in a similar situation, you’ll get the idea.

Intelligent detections – Just a heads-up that these settings are there. If you’re struggling with too many or too few alerts, it might be worth tweaking the minimum number of daily events that trigger a score boost for unusual activity or changing the default alert volume. There might also be some specific cases where you want to configure unallowed or third-party domains.


You can set up custom indicators here (Figure 21), including custom indicator variants.

A really useful one to set up is a custom indicator variant for the "Sending email with attachments to recipients outside the organisation" office indicator.
The process for setting this up is very simple, you choose your base indicator, give your new variant a name, optionally you can also provide a description. Next, you define activity to detect, so you determine whether foe example you would like to ignore activity involving items in a group or whether you only want to detect activity involving items in your selected groups.

You can configure it to only detect activity involving items in the “Free public domains” group (which should be available in the dropdown menu, assuming you checked it under the detection groups). The reason you might want this indicator variant set up is that the base indicator, "sending email with attachments to recipients outside the organisation," can generate a large volume of alerts. From experience, we all know that sending an email with an attachment to someone outside our organisation is a normal day-to-day operation, and in most cases, there won’t be anything suspicious or risky about it. However, if someone were to send an email with an attachment to a Gmail or Yahoo address, it might raise some eyebrows. Once you have the indicator variant set up, you can use it within your insider risk management policy, allowing you to refine your rules even further. For example, you could mark a user as high risk if they send a document containing at least one credit card number or credentials to a free public domain.
The below (Figure 23) shows how to set up a custom indicator variant for the free public domains.

Just like you can detect activity involving specific groups, you can also ignore activity from certain groups, like your business partners, auditors, and so on.
The below (Figure 24) shows how to set up a custom indicator variant for business partners.

Once you’ve set up your custom indicator variants, they'll appear in the policy indicators list.


A quick mention about the new (currently in preview) policy indicators like cloud storage, cloud services, and Microsoft Fabric indicators. These are pay-as-you-go indicators, so you’ll only pay for what you use – no upfront costs or commitment.

There are also indicators for Gen AI apps, so you can track activity within tools like Copilot or ChatGPT Enterprise.

Policy timeframes – It’s crucial to set these to the maximum so you get full coverage of user activity and can start getting real value from insider risk management straight away.
The timeframes you pick here will kick in when a user triggers a match for an insider risk policy. For example, if you set the activation window to 15 days and past activity detection to 30 days, and a user triggers a policy match on 1st July, the policy will pull user activity from 30 days earlier (1st June) (given that the prerequisites were covered, e.g. devices onboarded to Microsoft Purview, Microsoft Purview extension deployed to non-native browsers), and will keep recording new activity for the next 15 days (until 16th July).
Activation window (1 to 30 days) This decides how long policies will actively track activity for users, triggered when a user does something that matches the policy.
Past activity detection (0 to 90 days) This controls how far back a policy will go to check user activity, triggered when a user does something that matches the policy.

Priority User Groups – It might be a good idea to set up priority groups (note that these are separate from Entra ID groups, so you'll need to manage them manually as they aren't connected to Entra). These groups can be tricky to manage because they aren’t tied into Entra and are handled through the global insider risk settings blade. They’re especially useful if you want to focus on high-risk users, such as leavers (who might try to take corporate data when they resign), new staff (to ensure they follow business procedures), or VIP users.

Privacy – Most of the Purview solutions are designed with privacy in mind, and insider risk management is no different. You can choose whether to pseudonymise user details or show full usernames and display names. Just keep in mind that if you decide to pseudonymise them here, but you’re using adaptive protection with conditional access, account details will still be visible in Entra, so you’ll know exactly who did what.

*** *** ***

2. Create or edit an insider risk management policy
Navigate to: Purview Portal > Solutions > Insider Risk Management > Policies
Next step is to set up policies that monitor risky behaviour (e.g., excessive downloads, sensitive data transfers). Ensure these policies are tailored to your organisation’s risk tolerance.

I will not be going through how to set up a policy step by step, but rather point out some important bits.
Once you name your policy and optionally provide a description, follow the wizard to create a policy based on your organisational's needs.

You have an option in the below step (Figure 35) to prioritise content (for example, a highly sensitive SharePoint site, or sensitivie information types that could cause high-risk damage to the organisation if shared inappropriately.

Then, select your policy indicators you want to use within your policy.

Just because you have base and custom variant indicators available, doesn't mean you still need to rely on the base indicator that may be generating a lot of unnecessary alerts for your organisation.

In the next step (Figure 38), you can choose sequence detection options. If multiple suspicious activities are performed by a user in sequence, this will boost the user's risk score and, as a result, may assign an elevated risk to the user much faster.

Here (Figure 39), you need to choose a threshold type for the indicators. This means that each selected indicator uses thresholds to affect the activity’s risk score, which then determines whether an alert’s severity is low, medium, or high. Each threshold is based on the number of events recorded for an activity per day. While you can customise these thresholds, the list is quite long, so it’s worth keeping that in mind. You can also opt for the recommended setting, which applies thresholds based on your users’ activity patterns. This means the system will analyse user behaviour, and if it detects any anomalies, it will increase the alert's severity.

*** *** ***

3. Create insider risk level settings
Navigate to: Purview Portal > Solutions > Insider Risk Management > Adaptive Protection > Insider Risk Levels
Define thresholds for Elevated, Moderate, and Minor risk levels based on user activity patterns.
Insider risk levels – These levels determine the risk associated with a user's activity, based on factors like the number of exfiltration activities or whether their actions triggered a high-severity insider risk alert.
Insider risk policy – If the policy you set detects user activity that matches the insider risk levels defined in the dropdown menu in Figure 41, (Select a policy option), and these levels are part of a data loss prevention (DLP) or conditional access policy, the corresponding DLP or conditional access policy will be enforced for that user. In this case, we’re working with two conditional access policies.
Conditions for insider risk levels - This is your chance to edit and customise each risk level (elevated, moderate, and minor).

*** *** ***

4. Customise an insider risk level for your policy
Navigate to: Purview Portal > Solutions > Insider Risk Management > Adaptive Protection > Insider Risk Levels
Customisation ensures Adaptive Protection reacts proportionally. For example, a minor risk user may only be triggered when a user downloads a SharePoint file on to their local machine.
Go ahead, choose your insider risk management policy that you already have in place from the drop down menu under insider risk policy, and then customise your risk levels.

For example, you can select activities that you would perceive as the riskiest. In my case, a label downgrade or a removal , sending an email with attachments to people on a free public domain, and creating or copying files to USB would fall under an elevated risk. If performed in a sequence, that would also increase the alert severity and boost the user's risk score.



Make sure that you also customise the activity occurrences during detection window options.
You need to repeat the same process for each risk level.

Once you customise the conditions for insider risk levels, modify the bottom options (Figure 48) for past activity detection, insider risk level timeframe and insider risk lever expiration.

*** *** ***

5. Create or edit a conditional access policy
Navigate to: Entra Portal > Identity > Protection > Conditional Access > Policies
Now it's time to navigate to the Entra portal to set up our conditional access policies.
Here, you’ll enforce security measures like blocking risky users, requiring multi-factor authentication (MFA), or mandating acceptance of terms of use before accessing sensitive resources.
Modify your users and target resources scopes, as needed.
For the elevated insider risk, I would like to block user access, therefore I'm going to select conditions > Insider risk > set 'configure' to yes and select the elevated risk.

Under the grant options, I am selecting 'Block access'. I would suggest that you start with a report-only mode before you start enforcing the policy.

In another policy, I want to require the terms of use for users with a moderate or minor insider risk level. If you don't have any terms of use set up, now is a good time to get them ready. Check out Figure 54 and 55 to help with that process.
When you have the terms of use configured, you're ready to create the second conditional access policy scoped to moderate and minor risk levels.

Under the grant access options, select your Terms of Use.

*** *** *** ***
Terms of use
In Microsoft Entra, Terms of Use refer to the policies that an organisation sets to ensure that users agree to specific rules or conditions before accessing certain resources or applications. These terms are often used to safeguard sensitive data or ensure compliance with legal and regulatory requirements.
In other words, it is nothing else than a .pdf document listing rules for accessing and sharing resources and data.


*** *** ***

6. Turn on adaptive protection
Navigate to: Purview Portal > Solutions > Insider Risk Management > Adaptive Protection > Adaptive Protection Settings > Enable Adaptive Protection
This final step activates automated enforcement, ensuring that users flagged for risky behaviour experience the appropriate security measures without manual intervention.

Whenever ready, toggle the Adaptive Protection setting to on.

Go back to the Adaptive Protection blade on the left hand side and then select 'Conditional Access' to confirm that you can see the conditional access policies that utilise adaptive protection for insider risk propagated to the Purview portal.

Conclusion
Setting up Adaptive Protection for Insider Risk Management isn’t just about switching on a feature - it’s about configuring a well-calibrated framework that dynamically adapts security measures based on real-world risks. By following these steps, you can ensure that security responses are both effective and proportionate, reducing false positives while safeguarding your organisation against genuine insider threats.
In conclusion, I wouldn't recommend a big bang approach, start slow, fine tune your settings and your policies, use the report-only mode in Conditional Access before you enforce adaptive protection.

If you’ve got any questions or suggestions/ requests about the types of content you would like to see on here, let me know!
Comments