16.1 Roles and Permissions for Insider Risk Management

Microsoft Purview Insider Risk Management (IRM) is a compliance solution that helps organizations detect, investigate, and act on malicious and inadvertent internal risks such as intellectual property theft, data leakage, and security violations. The SC-401 skill measured here is not “how to write an IRM policy.” It is how to implement roles and permissions so the right people can configure the solution, the right people can investigate, and everyone else is blocked from seeing identifiable user activity. Microsoft documents IRM as built with privacy by design: users are pseudonymized by default, and role-based access controls and audit logs are in place to help ensure user-level privacy.

Treat IRM as a tenant-level governance tool, not a security operations console that every Global Administrator should live in. Microsoft’s own customer acknowledgment for IRM states that tenant administrators can surface insights related to an individual user’s behavior, character, or performance that are materially related to employment, and that customers remain solely responsible for using the service in compliance with applicable laws. That legal framing is why the exam cares about separation of duties as much as it cares about which portal blade you click.

Privacy by design: four principles you must be able to name

Microsoft’s Insider Risk Management privacy guide lists four core privacy principles. You should be able to explain each one in an exam scenario.

Pseudonymization. Identifiable user details such as user name and email address are removed from the investigation experience for the roles that review alerts. Personal data such as title, department, or location is also hidden so reviewers are less likely to bring bias or a conflict of interest into triage. Microsoft’s published example is that a user named John Smith is shown as a nonpersonal identifier such as ANON2340. Pseudonyms are on by default for Insider Risk Management Analysts and Insider Risk Management Investigators (the roles that review alerts and take action).

Role-based access controls. Only authorized IRM roles should see alerts and insights. Microsoft recommends stringent role-based access so people receive only the permissions their job requires. Organizations can assign users to specific role groups that manage different feature sets. The canonical separation is: admins can create, configure, and delete policies but cannot access or investigate alerts or cases; investigators can access and investigate alerts and cases but cannot configure policies. That sentence is the exam’s definition of IRM separation of duties.

Admin explicit opt-in. An admin with the right permissions must explicitly scope employees into a policy. Indicators that detect risky activities (for example downloading content from OneDrive or sharing SharePoint files with people outside the organization) are disabled by default. IRM does not start scoring those activities until an admin with the right permissions explicitly selects and opts in to one or more indicators in settings. This is a privacy control, not a missing license. If a question describes “no alerts after you created a policy,” one legitimate first check later in the IRM chapters is whether indicators were opted in; in this chapter, remember that opt-in is an admin action and investigators cannot turn indicators on unless an admin enables inline alert customization.

Audit logs. Microsoft Purview insider risk solutions record admin actions: creating or editing a policy, adding a user, viewing user activity insights, or adding indicators. Audit logs are enabled by default for Microsoft 365 organizations. IRM Auditors exist specifically so a privacy or internal-audit function can review those privileged actions without joining the investigation queue.

Microsoft also states that by default, global administrators do not have access to Insider Risk Management and Communication Compliance features as everyday solution users. That privacy statement coexists with a second, operational fact on the permissions page: members of Microsoft Entra Global Administrator and Compliance Administrator, and of Microsoft Purview Organization Management and Compliance Administrator, can assign users to IRM role groups and have the same solution permissions as Insider Risk Management Admins. For the exam, do not treat Global Administrator as the recommended daily IRM operator. Microsoft repeatedly says to use roles with the fewest permissions and to minimize Global Administrator use.

Six role groups, not one job title

Microsoft documents six role groups used to configure Insider Risk Management features. To make Insider Risk Management appear as a menu option in the Microsoft Purview portal and to continue configuration, a user must be assigned to one of these roles or role groups:

• Microsoft Entra ID Global Administrator
• Microsoft Entra ID Compliance Administrator
• Microsoft Purview Organization Management
• Microsoft Purview Compliance Administrator
• Insider Risk Management (the combined group)
• Insider Risk Management Admins

The six IRM-specific groups themselves are:

Two additional groups appear in the broader Purview permissions catalog and are easy distractors: Insider Risk Management Session Approvers (internal approval of session-based activities, without investigation access) and IRM Contributors (background services only). The skill measured for SC-401 is the six groups in the IRM permissions article.

Combined group versus segregated duties

You have two supported operating models.

Combined model. Add designated administrators, analysts, investigators, and viewers to the single Insider Risk Management role group. Microsoft calls this the easiest way to get started and a fit for organizations that do not need separate permissions for separate groups of users. The combined group includes roles such as Insider Risk Management Admin, Analysis, Approval, Audit, Investigation, Graph Reader, Data Connector Admin, Case Management, and others. Everyone in that group can both configure and investigate. That is convenient in a lab and a privacy problem in production.

Segregated model. Assign people to Insider Risk Management Admins, Analysts, Investigators, Auditors, and Approvers according to job function. This is the model Microsoft’s privacy guide describes: admins configure; analysts and investigators review; auditors watch the watchers. SC-401 scenarios that mention legal, HR, privacy, or works-council constraints almost always want the segregated model.

A high-yield Content Explorer distinction: Analysts cannot access the insider risk Content Explorer. Investigators can. Content Explorer is where investigators examine the context of files and messages associated with confirmed case activity. If a question asks who can open the actual documents behind an alert after it is confirmed to a case, the answer is a member of Insider Risk Management Investigators or the combined Insider Risk Management group—not Analysts, not Admins, not Auditors.

A second high-yield analytics distinction: Investigators cannot access analytics insights. Admins and Analysts can. Analytics scanning (evaluating potential insider risk before you create policies) is a configuration and planning activity, so Microsoft withholds it from the investigation-only investigator role.

Assigning permissions in the Microsoft Purview portal

The easiest way to assign IRM roles is to add the user to the appropriate role group on the Role groups page in the Microsoft Purview portal:

1. Sign in to the Microsoft Purview portal (https://purview.microsoft.com) with an admin account.
2. Select Settings (upper-right), select Roles and groups, then select Role groups.
3. Select the target role group (for example Insider Risk Management Admins), then select Edit.
4. Select Choose users, select the checkboxes for the users to add, then select Select and Next.
5. Select Save, then Done.

Timing trap: after you configure role groups, it might take up to 30 minutes for the permissions to apply to assigned users across the organization. Do not treat an immediate “I still do not see Insider Risk Management” as a failed assignment.

Zero-administrator trap: always keep at least one user in the built-in Insider Risk Management or Insider Risk Management Admins role group (depending on the model you chose) so the configuration cannot enter a zero administrator scenario when people leave the organization.

Least privilege for role-group management: to view role groups in Roles and scopes, a user needs to be a global administrator or assigned the Role Management role (assigned only to the Organization Management role group). Do not grant Organization Management just to let someone look at IRM alerts.

The Data Connector Admin role is required to add connectors on the Data connectors page. That role is included by default in Insider Risk Management and Insider Risk Management Admins (and in several other Purview groups such as Compliance Administrator and Organization Management). It is not a default role on Analysts, Investigators, Auditors, or Approvers. An analyst who can triage alerts still cannot create the HR connector unless you also give that account Data Connector Admin through a different group.

Administrative units: geographic or departmental scoping

You can use administrative units in IRM to scope user permissions to a geography or department. Microsoft’s example is a global company that creates an admin unit with a German scope so investigators only see activity for German users.

After you create admin units and assign them to role-group members, those members become restricted administrators with limited access to IRM settings, policies, and user data. Members who are not assigned administrative units remain unrestricted administrators with access to all settings, policies, and user data.

Published scoping effects you should remember:

• Restricted administrators cannot access alerts for users assigned to them through security groups or distribution groups added in administrative units. Those alerts are visible only to unrestricted administrators. Microsoft recommends adding users directly to administrative units so their alerts are visible to restricted administrators.
• Access analytics insights is not allowed if scoped for Admins and Analysts, and is never allowed for Investigators.
• Content Explorer remains unrestricted for Investigators even when the investigator is scoped—another reason Content Explorer is treated as a higher-privilege investigation surface.
• Configure global settings remains unrestricted for Admins even when scoped; configure policies is scoped.
• Configure Adaptive Protection, priority user groups, priority-user-specific policies, quick policies, and forensic evidence capturing requests are not allowed if scoped for Admins.
• Data risk graphs are not supported for scoped roles.

You can use adaptive scopes together with admin units. If one or more admin units scope role groups, those admin units limit the adaptive scopes you can select when you create or edit a policy.

Exam traps for this skill

• Do not put SOC analysts, HR investigators, and policy engineers in the combined Insider Risk Management group just because it is faster. The exam’s preferred production answer is segregated Admins / Analysts / Investigators / Auditors.
• Do not assume Global Administrator is required to open IRM. It can assign IRM groups and has Admins-equivalent solution permissions, but Microsoft recommends least privilege and IRM Admins for configuration.
• Do not give Analysts Content Explorer. That is the Investigator differentiator.
• Do not give Investigators analytics insights. That is an Admin/Analyst capability.
• Do not use Auditors as a cheaper Investigator. Auditors only view and export the IRM audit log.
• Do not forget the 30-minute replication window or the requirement to retain at least one IRM / IRM Admins member.

Later IRM chapters cover settings, indicators, templates, policy creation, forensic evidence configuration, Adaptive Protection levels, and the alert/case workflow. This chapter only establishes who is allowed to touch those surfaces.