Insider Risk Management

Microsoft Purview Insider Risk Management (IRM) detects risky behaviour by users inside the tenant — data theft by departing users, IP leakage, policy violations, security incidents — using built-in policy templates and machine learning across Microsoft 365 signals (sign-ins, email, file activity, Defender alerts, HR events). Designed with privacy preservation: anonymised display by default, tiered access (analysts see redacted data; investigators with higher roles can de-anonymise after due process), HR/Legal sign-off assumed. Common templates: data theft by departing users, general data leaks, security policy violations, risky AI usage, risky browser usage. Requires Microsoft 365 E5 or E5 Compliance licensing.

Why "insider" risk is a distinct problem from DLP

DLP answers "is this specific piece of content sensitive, and is it being moved in a way that violates policy" — it's a content-and-action rule engine that applies uniformly regardless of who's involved. Insider Risk Management answers a different question: "does this specific person's pattern of behaviour over time look like data theft, policy violation, or a security risk," correlating signals DLP never looks at in combination — a resignation notice in HR data, followed by an unusual volume of file downloads, followed by USB copy activity, followed by a browser upload to a personal cloud storage account. Any one of those signals alone might be unremarkable; the combination and sequence is what IRM's models are built to surface.

Worked example

An employee submits their resignation. IRM's "data theft by departing users" template, once the HR connector has ingested the resignation date, automatically raises the employee's risk score and begins weighting file and email activity more heavily for that user during their notice period. In the two weeks before their last day, the employee downloads several hundred files from a project SharePoint site they don't normally access at that volume, then emails a large attachment to a personal address. IRM correlates the anomalous download volume, the atypical site access, and the outbound email into a single alert for an investigator — rather than three disconnected, individually low-signal events buried in separate audit logs that nobody was actively correlating by hand.

Privacy-by-design architecture

IRM is deliberately built so that the people doing day-to-day analysis see pseudonymised user identifiers by default — "User 4471," not a name — and only a smaller, separately-permissioned group of investigators can de-anonymise a specific case, typically after HR or Legal has signed off that a formal investigation is warranted. This tiered-access design exists specifically so that a broad analyst team can triage alert volume without every analyst having standing visibility into named employees' detailed activity, which matters for works-council and privacy-regulation compliance in many jurisdictions (Sweden's codetermination rules among them) that require employee monitoring to be proportionate and governed.

Common pitfalls

Rolling out IRM without first involving HR, Legal, and (in many European contexts) employee representatives is both a policy risk and, in practice, a common reason implementations stall — insider risk monitoring of employee behaviour is exactly the kind of surveillance-adjacent capability that needs governance sign-off before switching on, not after. The second common mistake is turning on every built-in template at once; each template has its own tuning needs, and an org that enables the full template library without adjusting thresholds gets swamped with low-value alerts that make genuine signals harder to find.