Deploying Microsoft Purview Insider Risk Management: Policy Templates, Indicators, and Forensic Evidence

Insider Risk Management (IRM) is the one Purview solution where getting the policy right is the easy half. The hard half is operating it without turning your security team into a surveillance apparatus your works council, legal, and privacy office will shut down. The product is privacy-first by design — usernames are pseudonymized by default, the invasive capabilities need dual authorization, every analyst action is audited. Your job is to keep those guardrails on while still catching the departing engineer who just synced the source tree to a personal Dropbox.

Everything below lives in the Microsoft Purview portal (purview.microsoft.com -> Insider Risk Management). Unlike DLP, IRM policy authoring has no public Security & Compliance PowerShell surface — there is no New-InsiderRiskPolicy. The cmdlets you touch are the supporting ones: the HR connector upload script, the eDiscovery/case cmdlets (Get-ComplianceCase), and audit search. I will flag which surface is which so you do not hunt for a cmdlet that does not exist.

1. The insider risk model: signals, sequences, and pseudonymization

Three concepts drive everything:

• Indicators are the raw activities IRM collects (download from SharePoint, copy to USB, print, upload to a cloud service, rename-to-obfuscate). You enable them globally in settings and per policy: the global toggle decides what is collected, the policy toggle what scores.
• Triggering events decide whether a user is even evaluated. A user added to a policy with no triggering event is dormant — IRM ignores their activity until the trigger fires (a resignation date, a high-severity DLP alert, a Defender alert). This is the most misunderstood part of the product: in-scope is not the same as scored.
• Sequences and cumulative exfiltration are the intelligence layer. IRM detects sequences (collect -> obfuscate -> exfiltrate) and aggregates daily activity into insights with a severity score (Low 1-29, Medium 30-66, High 67-100). One insight can hold twenty events. Risk levels later count insights, not events.

Indicators are sensors, triggering events are the ignition, sequences are the correlation engine that turns “200 downloads” into “200 downloads, then a rename to .zip, then an upload to an unmanaged tenant — in the user’s final week.” That narrative is what makes an IRM alert defensible.

Pseudonymization is the default, and it matters legally. Under Settings -> Privacy, Show anonymized versions of usernames is on by default; analysts see AnonIS-xxxx aliases until they have cause and the role to de-anonymize. In regimes like Germany’s works council this is not polish — it is what makes deploying IRM lawful at all, so leave it on. One wrinkle: anonymization is not preserved once activity surfaces outside IRM — DLP alerts, Activity Explorer, and Conditional Access show real names for referential integrity. Tell your privacy reviewers up front.

2. Prerequisites: permissions, audit, and connected signals

Licensing and role groups

IRM requires Microsoft 365 E5 / E5 Compliance / the Insider Risk Management add-on. Adaptive Protection rides the same entitlement; forensic evidence adds a capacity model (trial up to 20 GB of clips, paid beyond). RBAC is deliberately segmented — assign people to the narrowest group that lets them do their job:

That separation between Analysts (see masked) and Investigators (see real) is the privacy control. Do not collapse it by putting everyone in Investigators.

Audit must be on

IRM is built on the unified audit log. It is on by default in modern tenants, but verify — if Audit is off, IRM sees nothing:

# Exchange Online PowerShell (not the S&C endpoint)
Connect-ExchangeOnline -UserPrincipalName admin@kloudvin.com
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
# If False:
Enable-OrganizationCustomization   # one-time, if the tenant has never been customized
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Connect DLP and Defender signals

Several templates are fed by other solutions, so connect them before authoring policies. DLP: the Data leaks family triggers on high-severity DLP alerts, so at least one DLP policy needs rules with Incident reports at High — Medium/Low never trigger IRM (see my Purview DLP authoring guide). Defender for Endpoint: the Security policy violations family imports MDE alerts — enable Defender for Endpoint -> Settings -> Advanced features -> Microsoft Purview Insider Risk Management connection. Cloud apps (Box, Dropbox, Google Drive, S3, Azure) flow in through Defender for Cloud Apps connectors as cloud exfiltration indicators.

3. Choosing policy templates

A template is a preset of indicators and a scoring model; pick one per policy (up to 100 policies per template). Match it to the scenario and the available signal, not a vague risk feeling:

For a first deployment, stand up two policies: Data theft by departing users (highest-signal, lowest-noise) and a broad Data leaks policy wired to DLP. Resist enabling the whole catalog — every active template competes for the same per-template user-scope budget and floods triage.

Run Analytics first (Analytics -> Scan). It performs a privacy-preserving, read-only sweep of the last ~10 days of audit data and tells you which exfiltration patterns actually exist in your tenant before you commit to thresholds — sizing a policy to reality instead of guessing.

4. Configuring indicators, thresholds, and the triggering-event model

Indicators are configured in two places: global indicators (Settings -> Policy indicators) are the master list of what IRM is allowed to collect tenant-wide (Office, Device, Cloud service, Healthcare/AI families); per-policy indicators are the subset that scores inside a given policy. Device indicators (USB copy, print, network-share copy, paste-to-browser, upload-to-cloud) only work after the device is onboarded — the same onboarding as Endpoint DLP and Defender for Endpoint, so a device already reporting to MDE is covered.

For each indicator you set the threshold mapping activity volume to Low/Medium/High. Start with Default (Analytics-recommended) thresholds, then go Custom on noisy ones once you have data — in a dev shop where 50 SharePoint downloads a day is normal, the default “High at 25 downloads” will scream, so raise the daily-occurrence floor. Risk score boosters amplify scores for real-risk context: activity above the user’s usual daily volume, activity on priority content (a labeled site, a sensitivity label, a SIT), or a user with a prior case. The “above usual activity” booster turns a flat counter into anomaly detection — enable it.

In the Triggering events step you choose what activates evaluation. For Data leaks you trigger on a DLP policy (high-severity alerts) or selected exfiltration indicators. The DLP route is precise but couples you to DLP scoping, and only Exchange/SharePoint/OneDrive DLP workloads trigger IRM — Endpoint, Teams, and Copilot DLP alerts do not. The indicator route (“trigger when the user copies to USB”) is self-contained and the cleaner starting point; add the DLP trigger once your DLP estate is mature.

5. HR connector and Entra account-deletion triggers for departing employees

The Data theft by departing users template needs to know who is leaving. Two ways to feed it.

Option A: Entra account deletion (zero infrastructure)

Select User account deleted from Microsoft Entra as the triggering event. When offboarding deletes (or soft-deletes) the account, IRM retroactively scores that user’s prior exfiltration. Zero setup — but it fires late: deletion usually happens on or after the last day, missing the notice-to-departure window where most theft happens.

Option B: HR connector (the real answer)

The HR connector imports resignation and termination dates so scoring starts the moment notice is given. Setup is four parts: a CSV, an Entra app registration, a connector in Purview, and a scheduled upload script.

CSV schema for the resignation scenario (column names are your choice — you map them in the connector wizard — but the data types are fixed). Dates are ISO 8601:

UserPrincipalName,ResignationDate,LastWorkingDate
sarad@kloudvin.com,2026-05-23T15:18:02.4675041+05:30,2026-05-29T15:18:02.4675041+05:30
pilarp@kloudvin.com,2026-05-24T09:15:49Z,2026-05-29T15:18:02Z

LastWorkingDate cannot be more than six months in the past or one year in the future from upload time. Fold multiple HR scenarios into one file with an HRScenario column (Resignation, Job level change, Performance review, …) mapped as the identifier — that is how one connector serves both the departing-user and risky-user templates. Each upload caps at 500 records; split larger exports.

App registration: register an Entra app, capture the tenant ID, app (client) ID, and a client secret — the connector and upload script authenticate as this app. Connector: Settings -> Data connectors -> Add connector -> HR (preview); select scenarios, map CSV columns (upload a sample file and pick from dropdowns), and copy the job ID from the confirmation page. Upload with Microsoft’s sample script (upload_termination_records.ps1 from the m365-compliance-connector-sample-scripts repo), which is provided as-is, so review it before scheduling:

# Firewall MUST allow webhook.ingestion.office.com or the upload silently fails.
.\HRConnector.ps1 `
  -tenantId  aaaabbbb-0000-cccc-1111-dddd2222eeee `
  -appId     00001111-aaaa-2222-bbbb-3333cccc4444 `
  -appSecret 'Aa1Bb~2Cc3.-Dd4Ee5Ff6Gg7Hh8Ii9_Jj0Kk1Ll2' `
  -jobId     11112222-bbbb-3333-cccc-4444dddd5555 `
  -filePath  'C:\HRConnector\employee_termination_data.csv'
# Success prints: "Upload Successful"

Then schedule it daily, so a resignation entered in the morning is scoring by evening. Two production-grade ways: Windows Task Scheduler on a hardened jump host (gMSA, highest privileges, fresh CSV pulled from the HRIS export each run); or Power Automate (Microsoft ships ImportHRDataforIRM.zip) — trigger on a new file in SharePoint/OneDrive, pull the secret from Azure Key Vault, POST to https://webhook.ingestion.office.com/api/signals. The Power Automate route is the better pattern: no standing secret on a VM, and it fits a “HR drops a file, ingestion happens” event model.

Treat the client secret like any ingestion credential — Key Vault, short rotation, never plaintext on disk. A leaked HR-connector secret lets an attacker inject fake resignation dates to trigger (or suppress) scoring on arbitrary users.

Validate the upload under the connector’s Download log — the RecordsSaved count must match your CSV row count.

6. Alert triage, case management, and escalation to eDiscovery

Once policies score, alerts queue under Alerts, and the workflow is a funnel. Triage the alert — read the activity timeline and the sequence/insight breakdown, then confirm (creates/links a case) or dismiss with a reason for the audit trail. Investigate in the case, which aggregates every alert, the user timeline, and (if configured) content and forensic clips; add case notes as part of the legal record. Act by sending a notice (a templated acceptable-use reminder — the right first move for inadvertent, low-severity risk), resolving, or escalating for investigation.

Escalation to eDiscovery is the bridge from “security suspicion” to “legal hold.” Escalating a case spins up a linked eDiscovery (Premium) case so legal can place holds, collect, and review with full chain of custody — without security ever touching mailbox/site content. That separation is deliberate: IRM finds the signal, eDiscovery does the defensible collection. The eDiscovery side is scriptable from Security & Compliance PowerShell:

Connect-IPPSSession -UserPrincipalName admin@kloudvin.com
# Inspect the eDiscovery (Premium) case created from an escalated IRM case:
Get-ComplianceCase -CaseType AdvancedEdiscovery |
  Where-Object Name -like "*Departing*" |
  Format-Table Name, Status, CreatedDateTime

Note IRM policy objects are not exposed here — only the case/eDiscovery side is. Plan your “as-code” story accordingly: policies are portal-managed and change-controlled by screenshot/runbook, not by cmdlet.

7. Forensic evidence capture configuration and consent controls

Forensic evidence captures visual clips of on-device activity around a risky event — the strongest investigative artifact IRM offers, and the most privacy-sensitive. It is off by default, an opt-in add-on, and gated by controls you must respect.

Prerequisites. A clip-storage capacity quota (trial up to 20 GB); clips auto-delete 120 days after capture, so download anything you must keep. Devices must run Windows 10/11 Enterprise, be onboarded to Purview, and have the Microsoft Purview Client installed (it does the capture; separate from MDE). Minimum 8 GB RAM, i5/Ryzen 5+, DirectX 11 integrated graphics (discrete GPUs not supported), 1920x1080.

The consent gate (dual authorization). Before any user can be captured, an Insider Risk Management Admin submits a capturing request that an Insider Risk Management Approver must approve. This is what keeps forensic capture from becoming covert surveillance — wire the Approvers group to legal/HR, not the SOC. No approval, no capture.

Capturing options. Specific activities captures only when a triggering event brings an approved user in-scope and a policy indicator fires — scoped, proportionate, the right default (e.g. capture 5 min before and 10 min after the user downloads SecretResearchPlans.docx). All activities is continuous capture; reserve it for an active, escalated investigation of one named person — it is the most invasive mode and the hardest to defend broadly. Always exclude desktop apps and websites (personal webmail, banking, social) to protect privacy and conserve capacity; pseudonymization still masks identities on the Forensic evidence tab for Analysts.

The defensibility test is proportionality: recording ten minutes around a confirmed exfiltration of a labeled secret is defensible; all-activity capture across a department is not. Capture the narrowest window that proves the act, exclude personal apps, keep the Approvers gate honest.

8. Adaptive Protection: feeding risk levels into DLP and Conditional Access

Adaptive Protection (AP) closes the loop: it converts IRM scoring into dynamic enforcement in DLP, Conditional Access, and Data Lifecycle Management — strong controls on the few risky users, zero friction for everyone else. Three built-in insider risk levels (distinct from alert severity) drive it: Minor (>=1 high-severity exfiltration activity), Moderate (>=2), and Elevated (>=3 high-severity exfiltration sequences, or one-plus confirmed high-severity alerts). All are customizable (criteria, severity, daily-occurrence counts, a 5-30 day past-activity window) and reset automatically after a configurable window or when the alert is dismissed / case closed.

The integration points are explicit:

• DLP: add the User's insider risk level for Adaptive Protection is condition to a rule; AP supports Exchange, Teams, and Devices. The classic shape: Minor/Moderate -> warn with override + policy tip; Elevated -> block. The same egress is allowed for a normal user and blocked for an Elevated one, automatically.
• Conditional Access: in the policy conditions, set Insider risk to Yes and pick the level. Pair with Block or a strong-auth grant, and start in report-only — AP’s quick setup deliberately creates the CA policy report-only so you do not lock out a department on day one.
• Data Lifecycle Management: for Elevated users, an auto-created retention policy preserves anything they delete from SharePoint/OneDrive/Exchange for 120 days — so a departing user cannot cover tracks by emptying their mailbox.

A minimal AP DLP rule, as the JSON the editor produces, makes the wiring concrete:

{
  "name": "Block egress for Elevated insider risk",
  "conditions": {
    "insiderRiskLevel": "Elevated"
  },
  "actions": [
    { "type": "RestrictAccess", "value": "BlockAccess" },
    { "type": "GenerateAlert", "severity": "High" }
  ],
  "locations": ["Devices", "ExchangeOnline", "MicrosoftTeams"]
}

Adaptive Protection is the payoff. Tuned IRM scoring becomes the trust signal a CA policy keys on — a user who just exhibited three exfiltration sequences is stepped up to phishing-resistant MFA (or blocked) for the duration, then returns to normal when the risk level resets. Risk-adaptive access, sourced from behavior, with no analyst in the loop.

Enterprise scenario

A platform team at a ~12,000-seat engineering company stood up Data theft by departing users with the Entra account-deletion trigger only — no HR connector — because “offboarding already deletes the account.” Six weeks in, a staff engineer left for a competitor and the team had nothing: the account was deleted on the last working day, IRM started scoring at that instant, and the actual exfiltration — a two-week drip of repo exports to a personal Google Drive during the notice period — had already aged out of the actionable window. The trigger fired after the horse had bolted.

The constraint was real: HR would not grant security standing access to the HRIS, and the works council could veto anything resembling continuous monitoring. So the fix had to (a) start scoring at resignation, not deletion, and (b) never put HR data on security-owned infrastructure.

They built an event-driven HR connector. HR’s nightly HRIS job already dropped a resignation export to a SharePoint library HR owned. A Power Automate flow — owned by HR, not security — triggered on that file, pulled the connector secret from Azure Key Vault, and POSTed to the ingestion endpoint. Security never touched the data; they consumed only the resulting pseudonymized risk signals. The flow’s core:

Trigger:  When a file is created (HR's SharePoint library)
Action 1: Get secret 'irm-hr-connector' from Azure Key Vault
Action 2: HTTP POST -> https://webhook.ingestion.office.com/api/signals
          headers: tenantId, appId, jobId; body: CSV content

They paired the policy with Adaptive Protection: a resignation date starts scoring on day one of notice, and once a departing user accumulates exfiltration sequences they hit Elevated, which via the AP -> CA condition forces re-auth and blocks source-control SaaS while the DLM policy freezes anything they delete. The works council signed off precisely because pseudonymization stayed on and forensic capture required their HR approvers to consent per user.

Outcome: resignation-to-scoring latency went from “after deletion” to under 24 hours, the HRIS stayed off security infrastructure, and the next departing-employee case had a complete sequence timeline plus preserved deleted content — handed straight to an escalated eDiscovery (Premium) case. The lesson: the Entra-deletion trigger is a demo, not a deployment. Real coverage starts at resignation, which means an HR connector — run event-driven, HR-owned, and secret-managed so privacy and security boundaries both hold.

Verify

• Audit is ingesting: Get-AdminAuditLogConfig shows UnifiedAuditLogIngestionEnabled : True.
• HR connector health: connector flyout -> Download log shows RecordsSaved equal to your CSV row count, with a recent timestamp.
• Triggering works: add a test user, simulate the trigger (e.g., enter a resignation date, or generate a high-severity DLP alert), and confirm the user moves to in-scope / active on the Users dashboard — not merely listed.
• Analytics ran: Analytics shows a completed scan with recommended thresholds, proving IRM can read your audit data.
• Pseudonymization holds: sign in as an Analyst-role account and confirm names are masked; confirm an Investigator-role account can de-anonymize.
• Forensic gate enforced: attempt to enable capture for a user and confirm it blocks pending an Approvers approval.
• Adaptive Protection flows: on a test user, force activity to Elevated, then confirm the linked DLP and CA policies list the user under Users assigned insider risk levels within the documented propagation window (up to 36 hours after enabling AP).

Checklist

• E5/E5 Compliance (or IRM add-on) licensing confirmed; forensic-evidence capacity provisioned if used
• Unified audit logging verified on (UnifiedAuditLogIngestionEnabled = True)
• RBAC segmented: Admins / Analysts / Investigators / Approvers assigned least-privilege; Approvers are legal/HR
• Pseudonymization left on; privacy/works-council review documented (and the “names leak outside IRM” caveat disclosed)
• Analytics scan run before setting thresholds
• DLP high-severity rules and/or Defender for Endpoint IRM connection wired as triggering sources
• Started narrow: Data theft by departing users + one Data leaks policy, not the whole catalog
• Global indicators enabled; per-policy indicators scoped; “above usual activity” booster on
• Departing-user trigger uses the HR connector (resignation date), not Entra deletion alone
• HR connector secret in Key Vault; webhook.ingestion.office.com allow-listed; upload scheduled and RecordsSaved monitored
• Case workflow defined: notice templates for low-severity, eDiscovery (Premium) escalation path for serious cases
• Forensic evidence: Purview Client deployed, Specific activities mode default, personal apps/sites excluded, Approvers gate honored
• Adaptive Protection: insider risk levels tuned; DLP insider risk level condition + CA Insider risk condition deployed in report-only first
• DLM 120-day preservation for Elevated users acknowledged/opted-in

Pitfalls

The failure modes are consistent across tenants. In-scope is not scored — adding users without a triggering event produces a roster that does nothing; always verify the active state. The Entra-deletion trigger fires too late to catch notice-period theft; use the HR connector. Medium/Low DLP alerts never trigger IRM — only High-severity DLP incident reports do, and Endpoint/Teams/Copilot DLP alerts do not trigger at all. Turning on every template at once burns the per-template user budget and drowns triage. Collapsing RBAC by putting everyone in Investigators destroys the pseudonymization control that may be your legal basis for running IRM. And all-activity forensic capture applied broadly is the fastest way to lose works-council trust and have the whole program pulled.

Run IRM as a privacy-preserving detection system with a closed loop: score from resignation forward, keep names masked until an Investigator has cause, escalate serious cases to eDiscovery for defensible collection, and let Adaptive Protection turn confirmed risk into automatic DLP and Conditional Access enforcement that resets itself. Source-control your connector script and Power Automate flow, monitor the upload log every cycle, and let behavior — not a static blocklist — drive who gets the stronger controls.