17.1 Configure Insider Risk Management Settings

Why tenant settings come before policies

SC-401 treats Microsoft Purview Insider Risk Management (IRM) as a sequence: roles and connectors first, then tenant settings, then the indicator catalog, then a policy template, then the policy itself. This section is the settings layer. Microsoft states that Insider Risk Management settings apply to all Insider Risk Management policies, regardless of the template you choose when creating a policy. If privacy, analytics, intelligent detections, priority user groups, or timeframes are wrong, every later policy inherits the mistake.

Open settings from Settings at the top of any Insider Risk Management page in the Microsoft Purview portal (purview.microsoft.com), then select Insider Risk Management. There is no per-policy Privacy or Analytics blade. Creating the actual policy, forensic evidence capture, Adaptive Protection insider-risk levels, and the alert-to-case workflow belong to later chapters—use this catalog to configure the tenant, not to investigate a case.

Detection groups, Microsoft Teams case channels, Power Automate flows, and priority physical assets also live under Settings. Know they exist; do not confuse them with the policy-creation wizard.

Privacy: pseudonyms by design

Microsoft documents IRM as privacy by design: users are pseudonymized by default, with role-based access control and audit logs. The Privacy setting still matters because an administrator can switch the tenant to show real names.

Two options:

• Show anonymized versions of usernames. A user such as Grace Taylor appears as a randomized pseudonym such as AnonIS8-988 in the IRM experience. The choice anonymizes all users with current and past policy matches and applies to all policies. User profile fields (name, title, alias, organization or department) are hidden on alert and case details.
• Do not show anonymized versions of usernames. Real names and profile fields appear for current and past matches.

Exam traps sit in the exceptions, not the happy path:

• Activity metadata and Content explorer are not anonymized. Names in the metadata of an activity, in file metadata in Content explorer, and inside file content remain visible even when the Privacy toggle is on.
• Provisioning still shows names. Usernames appear when you add users to existing policies or assign users to new policies.
• Exports split. Anonymization is not preserved when you export alerts through the exporting API or into Microsoft Purview eDiscovery. Anonymization is preserved when you export to CSV from alerts or cases.
• Data risk graph. With anonymized usernames enabled, you cannot use the data risk graph.
• Triage Agent. User names in prioritized alerts are not anonymized on the Triage Agent dashboard even when Privacy is on.
• Downstream enforcement. Adaptive Protection documentation notes that user names are not anonymized in Conditional Access or data loss prevention. IRM privacy does not rewrite DLP incident names.

Turning the setting off later reveals usernames for everyone who already had matches. Treat that as an HR and legal decision, not a casual demo toggle.

Analytics: scan before you commit to a template

Analytics lets you evaluate potential insider risk without configuring any insider risk policies. Results are aggregated and anonymized; reviewers cannot identify individual usernames. Microsoft states the scan accounts for all UPNs and identities that might move data outside the organization—user, system, guest, and non-person accounts.

Enable it from the Overview Insider risk analytics card (Run scan) or from Settings > Analytics. First insights can take up to 48 hours. When you first enable analytics you see one day of results; if you leave it on, each daily scan adds to the report up to a maximum of the previous 10 days. Analytics risk scoring uses up to 10 days of activity; insider risk policies use daily activity for insights. Microsoft does not publish a longer analytics window—do not invent one.

Sources included in every scan:

• Microsoft 365 audit logs (the primary source)
• Exchange Online (attachments emailed to external contacts or services)
• Microsoft Entra ID (risky activity associated with deleted user accounts)

If you configured the Microsoft 365 HR data connector, analytics also uses resignation and upcoming termination dates.

Analytics also feeds real-time indicator threshold recommendations when you later build a policy. Turning analytics off stops insight reports from updating and removes those real-time threshold insights.

User-level analytics is a separate pair of toggles: Show insights at user level on the Analytics page, plus Share user risk details with other security solutions under Data sharing. That combination publishes user activity summaries and insider-risk severity into DLP alerts, Communication Compliance, and Microsoft Defender entity pages—including for users not in any IRM policy. Enabling analytics requires membership in Insider Risk Management, Insider Risk Management Admins, or Microsoft 365 Global admin. Prefer the IRM admin roles over Global Administrator.

Intelligent detections: volume, downloads, domains, and Defender alerts

Use Intelligent detections to:

• Boost the score for unusual file download activity by entering a minimum number of daily events
• Raise or lower the mix of high, medium, and low alerts
• Import and filter Microsoft Defender for Endpoint alerts used by security-violation templates
• Specify unallowed domains (higher risk score; optional trigger)
• Specify third-party domains (alerts for risky browser download activity)

Global exclusions used to live here; they now have their own Global exclusions (preview) setting. An exam option that still says "exclude domains under Intelligent detections" is stale.

File activity detection. You enter a daily-event floor. Microsoft's example: if the floor is 25, and a user usually downloads about 10 files per day over the previous 30 days, a day with 20 downloads is unusual for that user but is not boosted because 20 is below 25.

Alert volume (tenant-wide):

Defender for Endpoint alert statuses. After Defender for Endpoint is integrated (previous chapter), Intelligent detections lets you import alerts whose triage status is Unknown, New, In progress, and/or Resolved. Import is daily. If you select New, In progress, and Resolved, the same Defender for Endpoint alert can create three IRM activities as the status changes. That is by design so investigators can follow triage, not a duplicate-alert bug.

Unallowed vs third-party vs excluded domains

• Unallowed domains (up to 500): activity involving the domain gets a higher risk score and can optionally participate in policy triggers. Example: email to gmail.com, or downloads from a domain you treat as hostile. Wildcards such as *.wingtiptoys.com match same-level subdomains; Include multi-level subdomains reaches deeper. CSV import is supported.
• Third-party domains (up to 500): list business domains you want scored for the device indicator Use a browser to download content from a third-party site—for example a sanctioned vendor portal that is not a Microsoft 365 property.
• Global exclusions: domains (and other items) that should not be scored at all.

Microsoft publishes 500 as the maximum for both unallowed and third-party domain lists. Do not invent a different cap.

Priority user groups

Users are not equal risk. Executives, highly privileged IT administrators, and people with a history of risky activity need closer inspection and more sensitive risk scoring. You define them in Settings > Priority user groups, not inside the template picker.

Creating or editing a group requires Insider Risk Management or Insider Risk Management Admins. Workflow: name (required; cannot be renamed after you finish), optional description, then members (search mail-enabled accounts, Select all, or upload a CSV whose column is titled user principal name). Microsoft publishes a maximum of 10,000 users per priority user group. Then you must assign at least one reviewer: the built-in Insider Risk Management, Insider Risk Management Analysts, or Insider Risk Management Investigators role groups, a mix of those groups, or a custom set of users. That restriction is how you keep a confidential-project group off the default analyst roster.

Two templates require a priority user group: Data leaks by priority users and Security policy violations by priority users. Deleting a group removes it from any active policy that used it; the policy then has no included users, sits idle, and does not create alerts. Priority user groups are not currently supported for admin units—unrestricted admins can still assign groups, but scoped admins cannot create those two policy types.

Enable the matching risk score booster under Policy indicators > Risk score boosters so membership actually raises scores. Selecting those templates is covered in section 17.3; creating the policy is a later chapter.

Policy timeframes (published ranges)

Policy timeframes set how far IRM looks after and before a triggering event. Microsoft publishes these ranges:

Configure them with sliders on Settings > Policy timeframes. A longer user-level activation window overrides a shorter global window. Microsoft's example: global activation 15 days, a temporarily added user set to 30 days—that user remains in-scope for 30 days.

Do not invent other numeric limits for timeframes. Microsoft does not publish a required exam value for the default slider position.

Exam traps for settings

• Settings are tenant-wide. A "per-policy privacy toggle" is a distractor.
• Analytics is not a policy. It is how you decide which template to pick later.
• Unallowed raises score; third-party feeds a specific browser-download indicator; exclusions suppress scoring.
• Email past detection is 10 days, not 90.
• Anonymization has holes (Content explorer, APIs, eDiscovery, Triage Agent, DLP/Conditional Access).
• Deleting a priority user group can silently idle the policies that depended on it.