Microsoft Purview Insider Risk Management (IRM) is a solution in the Microsoft Purview compliance suite designed to help organisations proactively identify and mitigate internal threats. This report provides an overview of IRM, guidance on deploying it in a small or medium-sized business (SMB) environment, best practices for effective use (including privacy and integration considerations), licensing/cost details in Australian dollars (AUD), and a summary of recent enhancements relevant to SMBs.

1. Overview: What is Microsoft Purview Insider Risk Management?

Microsoft Purview Insider Risk Management (IRM) is a cloud-based insider threat detection and mitigation solution within Microsoft 365’s Purview (compliance) suite. Its purpose is to help organisations minimise internal risks by detecting, investigating, and acting on potentially malicious or inadvertent activities performed by users[1]. IRM addresses modern workplace risks such as data leaks, intellectual property (IP) theft, confidentiality or policy violations, insider trading, fraud, and other inappropriate internal actions[1]. Unlike perimeter security tools, IRM focuses on authorised insiders (employees or contractors) whose behaviour might pose a threat, whether intentionally or by accident.

Key Features and Capabilities: Microsoft Purview IRM provides a rich set of features to monitor and manage insider risks:

• Machine-Learning-Driven Signals: IRM correlates a broad range of user activity signals across Microsoft 365 and Windows endpoints (and even some third-party platforms) to identify suspicious patterns[1]. For example, it can track file downloads from SharePoint, unusual email forwarding, mass file deletions, copying of files to USB devices, or abnormal Teams communications. These signals are analysed to generate risk indicators (such as “download of sensitive files” or “mass deletion”) and are evaluated by built-in analytics to determine if they deviate from normal behaviour[2][1].

• Risk Policies with Templates: Administrators can create insider risk policies using a set of predefined templates that target common scenarios[1]. There are over 10 ready-to-use policy templates covering cases like Data theft by departing users, Data leaks (general or by privileged users), Security policy violations, and specialised cases (e.g. “Risky AI usage” and “Patient data misuse”)[1]. Each policy defines the conditions (triggering events and risk indicators) to watch for – for instance, a “Departing user” policy might trigger when an employee is added to an HR exit list and starts downloading large amounts of confidential data. Policies also define which users or groups are in scope, which services/locations to prioritise (SharePoint, Exchange, endpoint, etc.), and the time window to observe. These templates enable quick deployment of industry-standard detection rules, which can then be customised to the organisation’s needs.

• Risk Scores, Alerts and Dashboards: When user activities match a policy’s conditions, IRM will generate an alert. The alert includes a risk score/severity (low, medium, high) calculated based on the frequency and criticality of the activities[1]. All active alerts are visible in the Insider Risk Management dashboard in the Purview compliance portal, where a risk analyst can triage them. The dashboard provides an overview of alerts by status, severity, time detected, and indicates any associated risk factors[1] (e.g. if the user has a history of prior incidents). This allows the organisation’s designated reviewers to quickly identify and prioritise alerts that need investigation. Alerts can be filtered and sorted to focus on those needing immediate attention (for example, all “High severity” alerts in the last 24 hours)[1].

• Case Management and Investigation Tools: For each alert (or group of related alerts) that warrants deeper investigation, IRM allows creation of a case. A case in IRM is a container that holds all information and evidence related to a particular insider risk incident. The Cases dashboard shows all ongoing cases, trends over time, and stats like average time to closure[1][3]. Inside a case, investigators have a rich toolkit:

  • A user activity timeline that charts the sequence of risk events by date and risk level[1]. Investigators can interactively explore what the user did (e.g. accessed 50 files, attempted to print a confidential document, etc.) before and after the alert, helping identify patterns or escalation.
    

  • Content explorer that automatically collects copies of files, emails, or messages related to the policy violation[1]. For example, if the alert was triggered by file downloads, the actual files or filenames can be reviewed; if it was an email-forwarding incident, the email content can be inspected. This provides crucial evidence in context.
    

  • Built-in workflow actions, such as the ability to dismiss benign activities, add notes, or escalate the case to eDiscovery (now called Advanced eDiscovery) for further legal hold and forensic investigation[1]. Escalation to eDiscovery (Premium) is useful if the incident might lead to legal action or requires broader content search beyond what IRM automatically collected.

• User Privacy and Role Separation: A fundamental principle of IRM is privacy by design. By default, usernames are pseudonymised in the IRM dashboard (e.g. shown as “User1”, “User2”) so that risk investigators focus on the behaviours first, reducing potential bias[1]. Investigators cannot see the actual user identity until they explicitly “Unlock” it (which is an auditable action) or if they have appropriate permissions to de-anonymise. Additionally, only users in specific Purview role groups (such as “Insider Risk Management Admin” or “Insider Risk Analyst”) can access IRM data[4][4]. This role-based access control ensures that insider risk investigations are handled by authorised personnel (for example, a security officer or HR investigator) and not visible to those who shouldn’t see sensitive details. All actions in IRM (viewing an alert, resolving a case, etc.) are logged for audit purposes to ensure accountability[1]. This privacy-focused design helps organisations implement insider monitoring ethically and in compliance with privacy laws, which is especially important in regions (like the EU or Australia) that have strict regulations on employee monitoring.

• Integration with Other Purview and Security Solutions: IRM does not operate in isolation; it benefits from and contributes to other Microsoft 365 security and compliance tools:

  • It leverages Microsoft 365 audit logs and other services as inputs. IRM uses the logs and events from Exchange, SharePoint, OneDrive, Teams, Windows, and even Defender for Cloud Apps to gather the signals it needs[1]. For instance, if you have Microsoft Purview Data Loss Prevention (DLP) policies, an act that triggers a DLP alert (like an attempt to email out a credit card number) can be consumed as a signal in IRM as well. In this way, IRM correlates with DLP – DLP might block or warn on a specific activity, while IRM looks at the pattern of activities around it to gauge user risk.
    

  • IRM is closely related to Communication Compliance, another Purview feature that scans communications (email, Teams chats) for policy violations like harassment or sensitive data sharing. While Communication Compliance focuses on reviewing message content, IRM focuses on user behaviour patterns. They complement each other: for example, if Communication Compliance flags a user for attempting to share confidential info via Teams, IRM can take that into account as a risk indicator. Microsoft even provides a combined workflow (via Microsoft Mechanics) to show how these solutions work together[1].
    

  • For serious incidents, IRM cases can be escalated to eDiscovery (Premium) as mentioned. This integration ensures that if legal investigation is required, all data collected by IRM flows into the eDiscovery workflow seamlessly[1].
    

  • Adaptive Protection: A newer capability in Purview allows dynamic adjustment of DLP or other controls based on IRM’s risk score for a user. For example, if IRM deems a user “high risk” (perhaps they have multiple serious alerts), the system can automatically impose stricter DLP rules on that user (like blocking any external sharing of files) via Adaptive Protection policies[3][3]. This showcases a powerful integration where IRM’s analytics inform preventative controls in real time.
    

  • Microsoft Defender Integration: In a security operations centre (SOC) scenario, insider incidents can appear similar to external attacks. IRM now integrates with Microsoft Defender XDR (Extended Detection & Response) tools used by SOC analysts. IRM’s insights (like the user’s risk level or history of data downloads) are surfaced in Defender’s incident pages[2][2]. This helps the SOC distinguish between a compromised account vs. a malicious insider. (We discuss this more under recent enhancements.) In short, IRM is part of the broader Microsoft 365 “inside-out” defence strategy, working hand-in-hand with other tools to provide a 360-degree view of risks.

In summary, Microsoft Purview Insider Risk Management serves as a centralized internal risk management hub – it enables SMBs to spot risky user behaviour early, investigate incidents thoroughly (with minimal privacy intrusion until necessary), and respond decisively (either by corrective action, enforcement through other tools, or involving HR/legal teams). It fits within the Microsoft Purview compliance suite as the solution focused specifically on people-centric risks inside the organisation, complementing other solutions that focus on data protection and external threats.

2. Step-by-Step Deployment Guide for an SMB

Deploying Insider Risk Management in an SMB environment involves preparing the tenant, configuring the tool, and tuning it to your organisation’s needs. Below is a step-by-step guide covering prerequisites, setup, and initial policy configuration.

Step 1: Licensing and Permissions. Before anything else, ensure your organisation’s Microsoft 365 subscription includes Insider Risk Management. IRM is considered an advanced compliance feature and is not included in the base SMB plans by default (for example, it’s not part of Microsoft 365 Business Premium)[5]. The section on Licensing and Costs later in this report details the options; commonly, SMBs will either utilize a Microsoft 365 E5 plan or a Microsoft 365 E5 Compliance add-on to get IRM. If you don’t yet have the licenses, Microsoft offers a 90-day trial for Purview solutions which could be used to pilot IRM at no cost[4]. Once licensing is in place, assign the IRM licenses to the user accounts that will be monitored and to the admins who will manage the system (typically you’d license all users for compliance features like IRM to be safe). Next, set up permissions: in the Microsoft Purview compliance portal, navigate to Roles and add the appropriate people to Insider Risk Management roles (e.g. “Insider Risk Management Admin” for those who configure policies, and “Insider Risk Management Analysts” for those who will review alerts)[4]. By design, Global Admins do not automatically see IRM—you must be in one of these IRM-specific role groups to access the insider risk dashboards.

Step 2: Turn on Audit Logging. IRM draws on M365’s unified audit log to get much of its signal data. For IRM to function, audit logging must be enabled for your tenant[4]. Most tenants have this on by default (and any Microsoft 365 Business Premium or E3/E5 tenant will have basic audit capabilities), but verify by going to the Audit section in the compliance portal. If it’s off, turn it on (note: after enabling, it may take a few hours to start recording events)[4]. Without audit logs, IRM policies won’t trigger because they have no data to analyze. Also ensure that users and administrators are aware that audit logging is active (for transparency).

Step 3: Optional – Insider Risk Analytics. Microsoft Purview IRM includes an Analytics feature that can be run in “analysis mode” without any active policies. This is optional but highly recommended, especially for first-time setup. The analytics scan combs through your existing audit logs to identify any activities or users that appear risky before you even configure formal policies[4]. Think of it as a baseline risk assessment. For example, analytics might surface that a particular user has been mass downloading files or that there’s an unusual spike in permission changes in SharePoint. Running this can help you pinpoint where to focus your policies (perhaps your organisation has more of a data leakage issue vs. HR-related issues, for instance). You can start an analytics scan from the IRM Overview page in the Purview portal by enabling “Insider risk analytics”. Give it at least a day or two (up to 48 hours) to complete the scan and generate the analytics report[4]. The output will highlight top risk factors and potentially recommend policy templates to implement. This step is particularly useful for an SMB to right-size their approach and not enable every policy blindly. (It’s worth noting that the analytics feature might require the higher-tier license as well, since it’s part of the IRM solution.)

Step 4: Configure Connectors & Indicators (if needed). Out-of-the-box, IRM will already use many internal signals from M365 workloads. However, you should consider if you need to configure any connectors for additional signals:

• HR Connector for Departing Users: If you plan to use policies related to employees leaving the company, you should feed IRM with information about separations. In an enterprise, this is often done via an HR system connector (e.g. connecting Workday or SAP SuccessFactors into Azure AD or directly into Purview). In an SMB, you might not have a fancy HR system – but you can still inform IRM of departure events by using the “User resignation” data connector in Purview or simply by updating the user’s profile in Azure AD with a termination date. Microsoft Purview can import a CSV or use Azure AD attributes to mark someone as scheduled to leave[6], which triggers the “departing user” condition in relevant IRM policies. Configuring this ensures that when someone is put on notice or given their resignation, IRM policies for departing users will properly scope that person and apply heightened monitoring during the critical window around their exit.
  

• Endpoint and Cloud App Indicators: If your organisation wants to monitor actions like files being copied to USB drives, printed, or uploaded to cloud services like Dropbox, ensure that Microsoft Defender for Endpoint (if available via your license) is deployed on your user devices. For SMBs using Microsoft 365 Business Premium, Defender for Business provides some endpoint DLP capabilities that integrate with Purview. Check that devices are onboarded in the Microsoft 365 Defender portal so that endpoint signal (like device file events) flow into IRM. Similarly, if you want multi-cloud visibility (e.g., to get alerts when someone moves files to an unsanctioned cloud service), you might have had to enable a preview connector. As of late 2024, IRM introduced multi-cloud indicators (for Box, Dropbox, Google Drive, AWS, etc.) that can be toggled on, provided you link an Azure subscription for billing (more on this in Recent Updates)[7][7]. Decide which of these indicators are relevant to your SMB and enable them in Insider Risk Management > Settings if needed. Many SMBs may primarily focus on the core Microsoft 365 signals, but it’s good to know the system can extend to other cloud sources if your users commonly use them (for example, if some departments still use Dropbox for file sharing, you’d want IRM to catch risky moves there as well).

Step 5: Create and Customise Policies. With groundwork laid, proceed to create your insider risk policies:

• Navigate to the Insider Risk Management section in the compliance portal and select “Policies”. Click “+ Create policy”. A wizard will guide you.
  

• Choose a Template: Pick a template that aligns with a risk you’re concerned about. For an SMB just starting, two common ones are “Data leaks” (to catch general exfiltration of sensitive info) and “Data theft by departing users” (to monitor users who leave). The template will pre-select a set of indicators and a trigger. For example, Data leaks might look at things like mass file downloads, sharing files externally, etc., without needing a specific trigger event. Departing users template, on the other hand, will focus on users flagged as leaving.
  

• Name and Description: Give the policy a meaningful name (e.g. “Contoso – Departing User Data Theft Policy”) and description so others know its purpose.
  

• Scope (Users/Groups): Decide which users the policy will apply to. You can include or exclude users or Azure AD groups. In SMBs, it might be fine to include everyone initially. Alternatively, you might exclude executive accounts at first if you’re concerned about privacy, or vice versa mark only a certain group as “priority users.” (IRM has a concept of priority users for heightened monitoring of key roles – you can configure a list of priority users in the settings. There are also separate template variants for priority users[1]).
  

• Indicators and Triggering Events: Depending on the template, you may have options to refine what activities to watch. For example, in a Data leaks policy you can choose to monitor only files with certain sensitivity labels or only activities in specific SharePoint sites. In a Departing user policy, you will confirm what constitutes the “flight risk” trigger (usually it’s when the user is added to the HR departure list or disabled account). Ensure the indicators (like file downloads, printing, emailing attachments, etc.) make sense for your environment. Microsoft’s defaults are usually a good start, covering a broad range of risky actions.
  

• Timeframe: Set how far back and forward to look around a trigger event (for policies that have one). For instance, watch 30 days before and 30 days after a user’s termination date. For continuous policies (like Data leaks), you’ll set a monitoring interval (e.g. alert on risky activities within a 7-day window).
  

• Thresholds and Alerting: Some policies let you adjust thresholds – e.g., only alert if more than 100 files are downloaded in a day. Initially, you might keep the default values until you gather some data on what’s normal. Templates often come with research-based defaults. You can also set whether to alert on every event or only if a certain combination of events occur. Keep in mind SMBs might have fewer events overall, so you might lower certain thresholds (e.g., 20 files downloaded by one user might already be unusual in a 10-person company, whereas in a 1000-person company it’s not).
  

• Review and Create: Finish the wizard to create the policy, and make sure to turn it from “Test” mode to “Active” if you want real alerts. (There is a mode where you can simulate policies without generating alerts, but in SMBs it’s usually fine to go live, especially after doing an Analytics scan).

Repeat the above to create multiple policies if needed. A cautious approach for SMBs is to start with one or two policies that address your top concerns rather than enabling everything at once – this prevents overwhelming your team with alerts. Over time, you can add more policies (for different scenarios) as you become comfortable managing them.

Step 6: Monitoring Alerts and Tuning Policies. Once policies are active, IRM will begin monitoring user activities. Alerts will appear on the IRM Alerts page. At this stage:

• Establish a routine for alert review. For example, your IT manager or security officer might check the IRM dashboard daily or get email notifications (you can configure alert digest emails) if something triggers. In a small business, the person in charge of IT or compliance often takes on this role.
  

• When an alert comes in, click into it to see details: which user (pseudonymised as UserX until you reveal), what activities triggered it, and why it was flagged (e.g. “User downloaded 50 confidential files and uploaded 10 files to a personal Dropbox” might be listed under activities). Each alert shows the severity (low, medium, high) and the status (e.g. “Needs review”)[1].
  

• Triage the alert: Determine if it’s a true risk or a false positive. For example, maybe an employee legitimately moved documents to a SharePoint site but IRM flagged it as unusual – upon checking, you realise it’s part of their job. You can then resolve the alert as benign (dismiss it). If it’s potentially concerning (not obviously benign), leave it open for deeper investigation (or immediately escalate to a case if it looks very serious).
  

• As you handle alerts, you’ll learn whether your policies are too sensitive or not sensitive enough. Adjust the policies accordingly in the Purview portal. This might include: changing thresholds (maybe require 200 files downloaded before alert to cut down noise), adding an exclusion (e.g. exclude the Finance group from a particular policy if their large data exports are always causing alerts but are expected), or including additional indicators to catch missed incidents. Policy tuning is an iterative process. The goal is to reach a point where when an IRM alert fires, it is something truly worth looking at. Microsoft provides guidance in the dashboard via the Analytics feature which can suggest threshold changes (if you enabled Analytics, it can recommend tuning adjustments in real-time)[3].

Step 7: Investigating Incidents and Taking Action. For alerts that are confirmed as actual issues, use IRM’s case management to dig deeper:

• Create a Case from the alert (or add the alert to an existing case if it’s related to an ongoing investigation). In SMBs, it’s unlikely you have too many simultaneous cases, but using the case feature helps keep a record of what’s been investigated.
  

• In the case view, examine the User Activity timeline to reconstruct the user’s sequence of actions[1]. For example, you might see the user signed into their account at 8 AM from a new location, then at 9 AM downloaded a customer list from SharePoint, at 9:30 AM copied that to a USB drive, and at 10 AM attempted to delete a bunch of files. Plotting this out can tell a story – maybe they were preparing to leave and tried covering tracks, or maybe their account was compromised by an attacker (compare with their usual pattern).
  

• Use the Content Explorer to open or download copies of the files in question[1]. Check if the content is indeed sensitive. Sometimes IRM might flag a bulk action that isn’t actually harmful if the files are benign. Conversely, it might find the user also emailed those files out – the content explorer would show the email.
  

• Document findings in the case notes. If multiple people are involved in response (maybe an external IT consultant or a manager), you can share the case report with them (there’s an option to email a link to the case or export a summary).
  

• Decide on the response: Since SMBs may not have dedicated HR or security investigators, this likely involves leadership. You might have a conversation with the user to get an explanation, or you might immediately revoke their access if malfeasance is evident. IRM itself can’t automatically punish a user, but you can integrate it with other tools for response. For example, if you confirm that a user is leaking data intentionally, you could create a Power Automate flow that, when an IRM alert is tagged high severity, it alerts management and locks the user’s account. In smaller setups, manual action (disabling account, asking the user’s manager to follow up, etc.) is more likely.
  

• If the incident could have legal implications (e.g. theft of intellectual property), escalate the case to eDiscovery (Premium). With a click, IRM can send all its collected data to an eDiscovery case where legal teams can do a broader content search, preserve data (legal hold), and eventually export data for legal proceedings[1]. This is more relevant if you plan to pursue the matter legally or need to provide evidence to authorities.

Completing these steps sets up Microsoft Purview IRM in your SMB environment and initiates an ongoing cycle of monitoring and improvement. Remember that insider risk management is not a “set and forget” tool – it requires active management and periodic reassessment of policies as your business evolves. That said, after the initial heavy lift of configuration and tuning, many SMBs find that only a modest amount of time each week is needed to review IRM alerts once the system is calibrated to your normal operations.

3. Best Practices for Effective Use in SMBs

Implementing Insider Risk Management is not just a technical exercise – it also involves process and culture. Here are recommendations and best practices tailored for SMBs to use IRM effectively:

• Target the Most Relevant Risks: Align IRM with your specific business context. For example, if you’re a software development startup, source code leakage might be your top concern – focus on policies that watch for large code repository downloads or sharing code outside approved channels. If you’re a professional services firm, client data confidentiality would be key – a policy for detecting bulk client file downloads or unusual email forwarding might be priority. Start with 1-3 core policies that cover your greatest “insider worry” scenarios rather than enabling all templates. This keeps management manageable and addresses the issues you care about most. You can always broaden coverage later as needed.

• Tune Noise Down, Signal Up: In a smaller organisation, certain defaults may be too broad or trigger too often. Don’t hesitate to adjust sensitivity. For instance, a template might consider 5 deleted files as a risk – but if every employee typically deletes dozens of files (like cleaning up folders), that threshold is too low for you. Increase it to something more meaningful. Conversely, if something is very sensitive in your context (say any email sent to a personal address should be flagged), you might tighten a rule. Take advantage of IRM’s analytics recommendations if available – the system can suggest threshold changes to reduce unnecessary alerts[3]. The end goal is that when an alert comes through, it truly requires attention. During initial rollout, plan to spend a few weeks refining the policies. This investment will pay off by saving you time later and avoiding “alert fatigue”.

• Regular Alert Triage and Response: For IRM to be effective, you need a consistent process to handle its output. Define who will review alerts and how often. In an SMB, this could be a role for the IT administrator, security officer if you have one, or a managed service provider (MSP) if you use one. Treat it similarly to how you handle antivirus or firewall alerts – it’s part of the security monitoring routine. We recommend checking the IRM dashboard at least once a day or set up email notifications for new High severity alerts, so you don’t miss something critical. When reviewing:

  • Document decisions: If you dismiss an alert as false positive, add a note why (IRM allows notes on alerts/cases). This builds a knowledge base, so if another admin steps in, they understand the history. It also helps if you later need to explain your monitoring actions (for audit or compliance).
    

  • Use the case management even for moderate incidents. It keeps things organised. For example, if User A triggers small alerts that on their own aren’t alarming but collectively seem suspicious, open a case to tie them together. You can keep that case open and see if a pattern emerges.
    

  • Follow through on remediation: An alert that turned out valid should result in an action. That action might be as light as a coaching conversation with the employee or as heavy as termination or legal action, depending on severity. Make sure there’s a feedback loop – if an incident occurs, assess if additional controls are needed to prevent it in future (more training for staff, new DLP rule, etc.). IRM’s job is to shine a light on risky behaviour; it’s up to the organisation to remedy the root cause.

• Privacy, Ethics, and Communication: SMBs often have close-knit teams, and introducing insider monitoring can raise trust concerns. While IRM is designed with privacy features (e.g. pseudonymisation) to mitigate this, it’s wise to be transparent with your employees to the extent possible. Best practice is to include a section in your employee handbook or IT policy stating that “the company may monitor user activities and communications for security and compliance purposes.” Emphasise that this is to protect the business and employees from risks, not because of lack of trust. In some jurisdictions (like certain Australian states, EU countries, etc.), employee monitoring requires consent or at least notification – make sure you comply with any such requirements. Avoid over-monitoring: use IRM to address genuine risks and not to spy on trivial matters. For example, do not use it punitively to track minor policy infractions unrelated to security (like using office internet for personal browsing – that’s not what IRM is for). Maintaining professionalism and respecting privacy will help ensure that IRM does not erode workplace morale. Only a very small group (maybe just one person in IT plus a manager or HR partner) should have access to IRM data. This prevents gossip or misuse of the sensitive information that could come up during an investigation. All these measures build an environment where employees can accept the idea of monitoring as a safety net rather than feeling constantly surveilled.

• Leverage Integration with Other Tools: Use IRM in concert with the rest of your Microsoft 365 security stack:

  • If you have Microsoft Defender for Endpoint (part of Business Premium or as an add-on), ensure its features like endpoint DLP are enabled. This will feed IRM with rich device-level events (e.g. copying to USB, printing docs) that purely cloud-based monitoring might miss. It also allows you to take device-focused actions if needed (like isolating a machine).
    

  • Consider enabling Microsoft Purview Communication Compliance (if licensed) for things like acceptable use monitoring (e.g. detecting harassment in Teams or inappropriate sharing of data in chat). While communication compliance is separate, any serious findings there (like someone repeatedly trying to share confidential info via chat) can inform your insider risk picture. In fact, Microsoft has enabled certain Communication Compliance signals to flow into IRM as of recent updates[3]. For example, if a user is warned by a communication policy for attempting to share sensitive info, IRM can treat that as an indicator of potential risk.
    

  • Use Azure AD (Entra ID) risk signals in conjunction: If Azure AD Identity Protection flags a user as high risk (say their credentials were detected in a leak), be extra vigilant with their insider risk alerts – it could mean an external actor is using an insider’s account. Interestingly, IRM now shows Entra ID compromised user alerts within its dashboard for enriched context[3]. So a best practice is to monitor those correlations; a user with both an IRM alert and an Identity Protection alert might point to account compromise rather than malicious intent.
    

  • If you have Microsoft Teams or email flows set up for IT, you might integrate IRM alerts there for quicker response. For instance, you could use Power Automate to post a message in a private IT Teams channel whenever a high-severity IRM alert occurs, ensuring it’s seen promptly even if admins are not watching the portal.
    

  • Respond holistically: IRM might highlight a problem that requires changes elsewhere. If, for example, IRM alerts show a user accessing a confidential SharePoint site they shouldn’t, the fix might be to adjust SharePoint permissions for that site (a preventive measure), not just to chastise the user. Similarly, frequent near-miss incidents (where IRM catches risky behaviour) might signal a need for employee training on security policies. Use IRM as feedback to improve your overall security posture.

• Periodically Review and Update IRM Configuration: At least twice a year (or whenever major changes happen in your org), review your IRM settings:

  • Are the right people in the IRM roles? (E.g., if an admin left the company, remove their access.)
    

  • Do the policies still align with current business priorities and threats? You might add new ones as new risks emerge (for example, if you adopt a new tool or if there’s a rise in a certain risky behaviour industry-wide).
    

  • Check Microsoft’s updates to IRM (see next section) – new features or policy templates might be available that could benefit your SMB. Incorporating new capabilities (like the new “Risky browser usage” template or improved analytics) can increase the effectiveness of your insider risk program.

Overall, effective insider risk management in an SMB boils down to focus, balance, and follow-through: focus on the biggest risks, balance security with privacy and culture, and follow through on alerts with consistent action. When implemented with care, IRM becomes a valuable early-warning system for internal issues and fosters a security-conscious workplace.

4. Licensing and Cost Considerations (AUD) for SMBs

Microsoft Purview Insider Risk Management is available to SMBs, but it typically requires premium licensing. This section outlines the licensing options and costs, with prices in Australian dollars (AUD). All prices are per user, per month (excluding GST unless stated otherwise).

License Options for IRM in SMB: