The big shift in 2026 isn’t just who tries to break in. It’s how often they simply log in.
For Norwegian organizations, including small ones, this means the line between “external attacker” and “insider risk” has become much less useful in practice. If an employee is phished, or an account is compromised another way, activity quickly looks like legitimate use. Then the question isn’t just whether you stop the break-in. You also have to detect that an apparently normal user suddenly behaves like a risk.
This is where Microsoft Purview Insider Risk Management can be relevant: not as a surveillance project, but as a control set to detect, investigate, and handle incidents like data leaks, IP theft, fraud, and security policy violations. Microsoft describes the solution like this in the official documentation:
Why this isn’t just a problem for the big players
Many smaller organizations hear “insider risk” and think of disloyal employees, industrial espionage, and large enterprises. That’s too narrow.
In practice, this is often a question of:
- compromised accounts
- incorrect use of data by completely ordinary employees
- poor offboarding
- sharing sensitive documents to the wrong place
- using Copilot and other AI features without good data controls
The point is simple: When an attacker uses valid identity, it helps little to just think perimeter, firewall, and “outside-in.” You then have to look at user behavior, data access, classification, and activity signals together.
This isn’t a Microsoft product fact. It’s the practical consequence of how attacks actually look now.

What Purview Insider Risk Management actually does
Microsoft documents that Insider Risk Management is built to detect, investigate, and act on internal risks in the Purview portal, and that the solution supports scenarios including data leaks, risky users, departing users, and security policy violations.
In practice, this means you can build controls around, for example:
- data leaks
- departing users
- risky users
- security policy violations
But here’s the important part: These policies only have value when they’re connected to actual signals and actual ownership. An empty portal is still an empty portal even if the license is in place.

This is not “switch on and be secure”
The biggest mistake I see is believing IRM is a feature you enable and then you’re done. That’s wrong.
Microsoft documents several operational prerequisites:
- some templates require their own signals or integrations
- data leaks require at least one DLP policy
- security policy violations require integration with Defender for Endpoint
- some scenarios can use the HR connector
- regional support must be checked against Azure dependencies
- each user who should benefit from the service must be licensed according to Microsoft’s service description
Sources:
Privacy by design is good. It doesn’t absolve you of responsibility.
An important reason many hesitate with Insider Risk Management is privacy and labor law. That’s understandable.
Microsoft documents that the solution is built with privacy by design, with pseudonymization of users by default, role-based access, and logging to support privacy and control.
That’s good. But it isn’t the same as the solution being “unproblematic.”
When you combine:
- HR data
- user activity
- content insights
- alerts and investigation
…you move straight into an area where the organization must have:
- a clear purpose
- defined roles
- internal policy
- a process for notification and handling
- local legal review
Technology can reduce risk. It can’t make that judgment for you.

Start with few signals, not all signals
For most Norwegian organizations, the best start is not to turn on everything. That yields the most noise, the most internal unrest, and the least learning.
A better start is to prioritize 2–3 concrete scenarios:
Data exfiltration from common collaboration surfaces
Start with data leaks, but only if you actually have DLP policies that mean something.Departure or role change
Departing users can be useful if offboarding is a real problem area and HR processes are mature enough.Suspicious use combined with security signals
Security policy violations are interesting when Defender for Endpoint is already in operation and you actually work incidents across security and compliance.
The important thing is to choose scenarios you can follow up operationally, not scenarios that look good in a PowerPoint.
Who should own this?
In many environments, Purview ends up in a gap between IT operations, security, compliance, and HR. That’s a bad idea for Insider Risk Management.
You should at least clarify:
- who gets to see alerts
- who can create and handle cases
- who can de-anonymize users
- when HR or management should be involved
- when a case should be escalated to eDiscovery or another formal investigation
Microsoft documents connections to both eDiscovery (Premium), Defender-related signals, and other integrations, but that only makes role governance more important, not less.
What about SMBs: is this worth the cost?
The short answer is: sometimes.
The longer answer is that many smaller organizations don’t need the full breadth of Purview. They need enough to:
- reduce risk of incorrect sharing and exfiltration
- get better signals when an account is used abnormally
- connect identity, data, and activity
- have a control model for Copilot and other AI use
If you lack the foundation, for example classification, DLP, role model, and simple governance, IRM will quickly become an expensive layer of noise on top of a messy base.
So assess cost/benefit brutally honestly:
- Do you have actual datasets you’re worried about?
- Do you have people who can follow up alerts?
- Do you have DLP or labels that already mean something?
- Do you have a real need for investigation and traceability?
If the answer is no to all of this, start somewhere else first.
Insider risk and AI: now it ties together
In 2026 it makes little sense to discuss insider risk without talking about Copilot and AI governance.
Microsoft shows Purview controls for Microsoft 365 Copilot and Copilot Chat in connection with DLP, sensitivity labels, DSPM, and Insider Risk Management.
That doesn’t mean IRM magically solves AI risk. It means you now have to view these controls together:
- What data can Copilot reach?
- What is classified?
- What is stopped by DLP?
- What is detected as risky use?
- Who owns the follow-up?
This is where many organizations will fail: They treat Copilot as productivity, DLP as compliance, and insider risk as HR/security. In reality this is the same governance problem.
A practical start guide
If you want to test whether IRM is relevant in your organization, I would do this in this order:
Clarify purpose
What are you actually trying to detect: data leaks, poor offboarding, suspicious use, or policy violations?Check license and region
Don’t start with design before you know the service and dependencies are actually supported for your environment.Define roles and privacy model
Who should see what? Who can de-anonymize? Who should approve investigations?Start with one or two scenarios
No more.Connect the signals that actually have quality
DLP, Defender for Endpoint, HR data, or other signals only if you trust them.Do tuning before making this operational
Noise is the fastest way to lose trust in the whole setup.Tie this to AI governance
If you use Copilot, data controls and insider-risk assessments must be viewed together.

What you shouldn’t do
Some classic mistakes:
- turning on more templates than you can handle
- granting too broad access to alerts and cases
- importing HR data without a defined purpose
- believing pseudonymization removes legal responsibility
- viewing IRM in isolation from DLP, labels, and identity
- using the solution as general employee surveillance
The last is particularly important. If the organization can’t explain why this exists and what the boundaries are, you have a governance problem before you have a technical problem.
Honestly?
Insider Risk Management matters more in 2026 than the name suggests.
Not because all organizations have disloyal employees, but because compromised accounts, incorrect use of data, and AI-driven information flow make “internal” and “external” risk blend into each other.
For Norwegian organizations, the real value isn’t to monitor people more. It lies in connecting identity, data, signals, and follow-up in a way that actually captures risk when the attacker looks like a normal user.
But only if you start narrow, govern tightly, and hold privacy and labor law as highly as the technology.
