Practical detection scenarios, policy configuration, triggering events, and investigation workflows
Microsoft Purview | Insider Risk Management | Data Exfiltration | DLP | AI Security
An employee downloads hundreds of confidential files before leaving the company. Another copies sensitive documents to a USB drive. A third shares internal information through an external AI application.
Are these malicious activities, legitimate business operations, or accidental mistakes?
This is precisely the challenge Microsoft Purview Insider Risk Management (IRM) is designed to address.
IRM helps security and compliance teams identify potentially risky activities by correlating supported signals across Microsoft 365, endpoints, and connected services.
Unlike traditional Data Loss Prevention (DLP), which focuses on identifying and controlling policy violations, Insider Risk Management adds user-centric context, risk indicators, and behavioral analysis.
In this article, we’ll explore five practical insider-risk scenarios and explain how to detect them using Microsoft Purview.
1. Understanding How Insider Risk Detection Works
Before configuring policies, it’s essential to understand four concepts.
| Component | Purpose |
|---|---|
| Triggering event | Brings a user into scope for risk evaluation |
| Policy indicator | Defines which supported activities contribute to risk scoring |
| Risk score | Helps assess and prioritize potentially risky activities |
| IRM alert | Signals activity that meets the policy’s alerting criteria |
For example, copying a file to a USB device may be an enabled indicator.
However, the activity does not necessarily produce an IRM alert.
The user must be within the relevant policy scope, triggering requirements must be satisfied, and applicable scoring and alert thresholds must be met.
Microsoft also provides Activity explorer for reviewing supported activities collected through enabled global indicators.
Important: An IRM alert represents potential risk. It does not establish malicious intent.
Scenario 1: An Employee Copies Confidential Files to a USB Drive
Business scenario
An employee working in the finance department accesses confidential financial documents stored in SharePoint Online.
The employee downloads several files to a managed workstation and copies them to a USB drive.
This may represent unauthorized data transfer, particularly if the documents contain financial records or other sensitive business information.
Relevant Microsoft Purview capabilities
Recommended policy template: Data leaks
Relevant indicators:
- Files downloaded from SharePoint
- Files copied to removable USB storage
- Supported endpoint exfiltration activities
Prerequisites
Before configuring this scenario:
- Verify appropriate Insider Risk Management licensing.
- Onboard supported devices to Microsoft Purview Endpoint DLP.
- Enable the relevant device indicators in IRM settings.
- Configure an appropriate Data leaks policy and triggering event.
- Ensure the test user is included in the policy scope.
Configuration walkthrough
Navigate to:
Microsoft Purview → Insider Risk Management → Settings → Policy indicators
Enable the relevant Office and Device indicators.
Next, navigate to:
Insider Risk Management → Policies → Create policy
Select Data leaks.
Choose the relevant users or groups.
For the triggering event, use a supported custom exfiltration indicator if available for your policy configuration, or another qualifying trigger.
Include the USB and SharePoint-related indicators in the policy.
Configure suitable thresholds and review the policy before activation.
Controlled validation
Using an authorized test account:
- Create a synthetic confidential document.
- Store it in a SharePoint test site.
- Download it to an onboarded test device.
- Copy it to an approved test USB device.
- Review Activity explorer and any resulting IRM alerts.
Expected investigation evidence
Depending on the supported telemetry and configured indicators, investigators may see:
- User activity
- File-related information
- Device-related activity
- USB transfer activity
- Risk score contribution
- Associated activity sequence
Architect’s note: USB copying is an indicator, not a guarantee of an alert. Validate both the trigger and the policy’s scoring configuration.
Scenario 2: A Departing Employee Downloads and Transfers Company Data
Business scenario
An employee has submitted a resignation and is scheduled to leave the organization in two weeks.
During this period, the employee downloads numerous confidential documents and shares selected files externally.
The organization wants to identify potentially risky data movement associated with employee departure.
Recommended IRM policy
Policy template: Data theft by departing users
Relevant indicators
- SharePoint and OneDrive downloads
- External file sharing
- Copying files to removable storage
- Uploading files to supported cloud services
- Supported email-related exfiltration activities
Triggering requirements
The departing-user template supports employment-related triggering events, including:
- Resignation or termination dates supplied through a supported HR connector
- Supported Microsoft Entra account deletion events
These triggering methods have different operational implications.
An HR connector can provide advance notice of a planned departure, whereas account deletion may occur at or after offboarding.
Configuration walkthrough
Navigate to:
Insider Risk Management → Policies → Create policy
Select Data theft by departing users.
Configure the relevant triggering source and policy scope.
Enable the required indicators and configure risk thresholds.
Review the policy timeframes, including the available past-activity detection and activation windows.
Controlled validation
Use a synthetic test identity and a properly configured test triggering event.
Perform authorized file downloads and sharing activities within the relevant evaluation window.
Review the resulting activity and policy health.
Expected investigation evidence
Investigators may be able to correlate:
- Employment-related triggering event
- File downloads
- External sharing activities
- Device or cloud transfer events
- Sequence detection results
- Risk scores and alerts
Architecture recommendation
Integrate the policy with a formal employee offboarding process.
However, avoid treating every departing employee as suspicious. Investigations should follow documented privacy and governance procedures.
Scenario 3: A User Sends Sensitive Information Outside the Organization
Business scenario
A user sends an email containing sensitive customer information to an external recipient.
Microsoft Purview DLP detects a policy match.
The organization wants to determine whether the event is isolated or part of a broader pattern of risky activity.
Recommended IRM policy
Policy template: Data leaks
Relevant integrations
- Microsoft Purview DLP
- Exchange Online
- Microsoft Purview Insider Risk Management
Important DLP indicator limitation
Microsoft documents support for the High Severity DLP Alert indicator for DLP alerts from:
- Exchange Online
- SharePoint Online
- OneDrive for Business
The indicator does not currently support alerts generated exclusively by Endpoint DLP, Teams, Microsoft 365 Copilot, on-premises repositories, or Power BI.
This distinction is essential when designing the integration.
Configuration walkthrough
First, create or identify an appropriate DLP policy.
For example:
Policy: MUGGH - DLP - Confidential External Sharing
Configure the DLP policy to detect synthetic sensitive information in an appropriate test scenario.
Then open:
Insider Risk Management → Settings → Policy indicators
Locate the DLP indicators section.
Select Add DLP policies and choose the relevant policy.
Enable the option to generate indicators from selected DLP policy alerts.
Save the configuration.
Next, create or update an IRM Data leaks policy and include the applicable DLP indicator.
Where using a high-severity DLP alert as the trigger, ensure that the DLP event meets Microsoft’s supported workload and severity requirements.
Controlled validation
- Create a synthetic sensitive document.
- Send it using an authorized test mailbox.
- Verify the expected DLP policy match.
- Check whether a qualifying DLP alert is generated.
- Review the configured IRM policy for the corresponding indicator and any resulting risk evaluation.
Expected investigation evidence
The investigator may see the qualifying DLP alert alongside other supported activities associated with the user.
For example, a user might have sent sensitive information externally and also downloaded an unusually large number of documents.
IRM can help evaluate these activities together.
Architecture recommendation
Do not assume that every DLP alert becomes an IRM alert.
In particular, a low-severity DLP alert should not be treated as a qualifying high-severity DLP trigger.
Scenario 4: A User Shares Confidential Information with a Generative AI Application
Business scenario
An employee copies internal financial information into a generative AI application to generate a summary.
The employee may believe this is a harmless productivity task.
However, the information could be confidential and unsuitable for disclosure to the selected service.
Recommended IRM policy
Policy template: Risky AI usage
Relevant indicators
Depending on the supported AI application and configuration, IRM can evaluate activities involving:
- Sensitive information shared with generative AI applications
- Supported AI prompts and responses
- Data movement associated with AI usage
- Other supported AI-related risk signals
Prerequisites
Confirm:
- Supported AI application coverage
- Applicable Microsoft Purview licensing
- Required endpoint or cloud integrations
- Relevant generative AI indicators
- Policy scope and triggering requirements
Not every AI website or application is supported through the same monitoring mechanism.
Configuration walkthrough
Navigate to:
Insider Risk Management → Settings → Policy indicators
Review the available generative AI indicators.
Enable those relevant to the organization’s supported AI applications.
Next, navigate to:
Insider Risk Management → Policies → Create policy
Select Risky AI usage.
Configure the users, triggering requirements, policy indicators, and risk thresholds.
Review the policy before activation.
Controlled validation
Use an authorized test account and synthetic information.
Perform a supported AI interaction that meets the configured indicator conditions.
Review the available activity signals and any resulting risk evaluation.
Expected investigation evidence
Depending on the supported integration, investigators may see:
- AI-related activity
- Relevant application or destination context
- Sensitive-information indicators
- Associated user activity
- Risk score contributions
Architecture recommendation
Combine IRM with Microsoft Purview DLP, Endpoint DLP, and other applicable AI data security controls.
IRM provides investigation context; it should not be treated as a universal replacement for preventive AI data protection policies.
Scenario 5: A User Collects, Exfiltrates, and Deletes Files
Business scenario
A user performs several activities over a short period:
- Downloads confidential files from SharePoint.
- Copies the files to an external destination.
- Renames selected files.
- Deletes local copies.
Individually, these activities might appear ordinary.
Together, they could indicate a potentially risky sequence.
Recommended IRM policy
Policy template: Data leaks
Advanced capability: Sequence detection
Understanding sequence detection
Microsoft Purview organizes supported sequence activities into four broad categories:
| Stage | Example |
|---|---|
| Collection | Downloading files |
| Exfiltration | Sharing or transferring files |
| Obfuscation | Renaming files |
| Clean-up | Deleting files |
Sequence detection identifies supported combinations of activities occurring in a configured order.
A sequence contains at least two relevant activities; all four stages are not required.
Configuration walkthrough
Navigate to:
Insider Risk Management → Policies → Create policy
Select Data leaks.
Configure the relevant users, triggering event, and indicators.
When the policy wizard presents sequence detection options, select the supported sequences relevant to the business scenario.
Configure sequence thresholds and complete the policy.
Controlled validation
Use a dedicated test account and synthetic documents.
Perform the activities in the order expected by the selected sequence.
Review the policy’s user activity and investigation views.
Expected investigation evidence
Depending on the configured detection and available telemetry, investigators may see:
- Related file activities
- Activity timestamps
- Sequence information
- File-related context
- Risk score contributions
Architecture recommendation
Sequence detection is especially useful when a single activity is insufficient to establish meaningful risk.
However, it should be combined with sensible thresholds, appropriate exclusions, and contextual investigation.
6. Quick Comparison of the Five Scenarios
| Scenario | Recommended policy | Key detection capability |
|---|---|---|
| USB data transfer | Data leaks | Device exfiltration indicators |
| Departing employee | Data theft by departing users | Employment-related triggers |
| Sensitive external email | Data leaks | Supported DLP alert indicators |
| Risky AI interaction | Risky AI usage | Generative AI indicators |
| Multi-step file activity | Data leaks | Sequence detection |
These are recommended policy designs. Actual detection depends on the configured triggers, supported indicators, licensing, and available telemetry.
7. Why an IRM Policy Might Generate No Alerts
A common deployment challenge is creating an IRM policy that never generates alerts.
Before assuming the product is malfunctioning, verify the following.
Policy scope: Is the test user included?
Triggering event: Has a qualifying event occurred?
Global indicators: Are the required indicators enabled?
Policy indicators: Are the appropriate indicators selected in the policy?
Device onboarding: Are relevant devices properly onboarded?
Integrations: Are required HR, DLP, Defender, or cloud integrations configured?
Thresholds: Are the configured risk thresholds appropriate for the test?
Policy health: Does the IRM policy report configuration problems?
Microsoft specifically documents missing triggers, insufficient indicators, missing devices, and scope problems as potential causes of policies failing to generate expected alerts.
8. Privacy and Governance Considerations
Insider Risk Management is not a tool for automatically declaring employees malicious.
Microsoft provides privacy-focused capabilities such as user pseudonymization by default, role-based access control, and auditing.
Before deploying IRM, organizations should define:
- Legitimate investigation objectives
- Authorized analyst and investigator roles
- User privacy requirements
- Evidence handling procedures
- Alert escalation processes
- Legal and employee-representation requirements
- Retention and investigation policies
For a proof of concept, use authorized test users and synthetic data.
9. Recommended Implementation Roadmap
For organizations introducing Microsoft Purview Insider Risk Management, I recommend a phased approach.
| Phase | Activities | Deliverables |
|---|---|---|
| Assessment | Review licensing, risks, data flows and governance | IRM assessment |
| Design | Select scenarios, indicators and triggers | Detection design |
| Foundation | Configure permissions, connectors and policy indicators | Technical readiness |
| Pilot | Validate selected risky behaviors | Test evidence |
| Optimization | Tune thresholds and investigate false positives | Detection tuning |
| Operations | Establish alert triage and case management | Operational procedures |
Start with a small number of clearly defined detection scenarios.
Expand coverage after validating the technical prerequisites, alert quality, and investigation processes.
Conclusion
Microsoft Purview Insider Risk Management provides a powerful way to identify potential insider risks across Microsoft 365 and supported connected environments.
But effective insider-risk detection requires more than enabling a policy template.
Security architects must understand how triggering events, indicators, risk scoring, thresholds, and investigation workflows work together.
The five scenarios explored in this article demonstrate how IRM can support the detection of:
- USB-based data exfiltration
- Data theft associated with employee departure
- Sensitive information shared externally
- Risky generative AI usage
- Multi-step suspicious file activities
The objective is not to monitor every employee action or assume malicious intent.
It is to identify meaningful risks, provide context for investigations, and protect organizational information responsibly.
Effective insider-risk management starts with the right detection scenarios—not with enabling every available indicator.
