Insider Risk Management i 2026: når trusselen loggar inn

Det store skiljet i 2026 er ikkje berre kven som prøver å bryte seg inn. Det er kor ofte dei berre loggar inn.

For norske verksemder, også dei små, betyr det at skiljet mellom «ekstern angripar» og «intern risiko» har blitt mykje mindre nyttig i praksis. Blir ein tilsett lurt i phishing, eller ei konto blir kompromittert på annan måte, ser aktiviteten fort ut som legitim bruk. Då er ikkje spørsmålet berre om du stoppar innbrotet. Du må òg kunne oppdage at ein tilsynelatande vanleg brukar plutseleg oppfører seg som ein risiko.

Det er her Microsoft Purview Insider Risk Management kan vere relevant: ikkje som eit overvåkingsprosjekt, men som eit kontrollsett for å oppdage, granske og handtere hendingar som datalekkasjar, IP-tjuveri, svindel og brot på tryggingsreglar. Microsoft skildrar løysinga slik i den offisielle dokumentasjonen:

Learn about Insider Risk Management

Microsoft si grunnside for kva Insider Risk Management er, kva scenario som blir støtta og korleis løysinga er bygd opp.

Kvifor dette ikkje berre er eit problem for dei store

Mange mindre verksemder høyrer «insider risk» og tenkjer på illojale tilsette, industrispionasje og store konsern. Det er for snevert.

I praksis er dette ofte eit spørsmål om:

• kompromitterte kontoar
• feil bruk av data av heilt vanlege tilsette
• dårleg offboarding
• deling av sensitive dokument til feil stad
• bruk av Copilot og andre KI-funksjonar utan gode datakontrollar

Poenget er enkelt: Når ein angripar brukar gyldig identitet, hjelper det lite å berre tenkje perimeter, brannmur og «utanfrå og inn». Då må du sjå på brukaråtferd, datatilgang, klassifisering og aktivitetssignal i samanheng.

Dette er ikkje eit Microsoft-produktfaktum. Det er den praktiske konsekvensen av korleis angrep faktisk ser ut no.

Kva Purview Insider Risk Management faktisk gjer

Microsoft dokumenterer at Insider Risk Management er laga for å oppdage, granske og handle på interne risikoar i Purview-portalen, og at løysinga støttar scenario som mellom anna datalekkasjar, risky users, departing users og security policy violations.

Get started with Insider Risk Management

Dokumentasjon for oppstart, styring, roller og føresetnader før du tek løysinga i bruk.

Learn about Insider Risk Management policy templates

Oversikt over policy-templatear og kva signal og avhengigheiter dei ulike scenaria krev.

I praksis betyr det at du kan byggje kontrollar rundt til dømes:

• data leaks
• departing users
• risky users
• security policy violations

Men her kjem den viktige delen: Desse policyane gir berre verdi når dei er kopla til faktiske signal og faktisk eigarskap. Ein tom portal er framleis ein tom portal sjølv om lisensen er på plass.

Dette er ikkje «skru på og bli trygg»

Det største mistaket eg ser, er å tru at IRM er ein funksjon du aktiverer, og så er du ferdig. Det er feil.

Microsoft dokumenterer fleire operative føresetnader:

• nokre templatear krev eigne signal eller integrasjonar
• data leaks krev minst éi DLP-policy
• security policy violations krev integrasjon med Defender for Endpoint
• enkelte scenario kan bruke HR connector
• regional støtte må sjekkast opp mot Azure-avhengigheiter
• kvar brukar som skal dra nytte av tenesta må vere lisensiert etter Microsoft si tenesteskildring

Kjelder:

Plan for Insider Risk Management

Planleggingsside for lisens, regionstøtte, avhengigheiter og føresetnader før ein set opp policyar.

Microsoft Purview service description

Offisiell tenesteskildring med lisensinformasjon og kva Purview-funksjonar som er tenant-level services.

Privacy by design er bra. Det fritar deg ikkje frå ansvar.

Ein viktig grunn til at mange vegrar seg for Insider Risk Management, er personvern og arbeidsrett. Det er forståeleg.

Microsoft dokumenterer at løysinga er bygd med privacy by design, med pseudonymisering av brukarar som standard, rollebasert tilgang og logging for å støtte personvern og kontroll.

Investigate Microsoft Purview Insider Risk Management activities

Dokumentasjon for alertar, saker, aktivitetar, retensjon og personvernmekanismar i den operative bruken.

Det er bra. Men det er ikkje det same som at løysinga er «uproblematisk».

Når du kombinerer:

• HR-data
• brukaraktivitet
• innhaldsinnsyn
• varsel og etterforsking

…så går du rett inn i eit område der verksemda må ha:

• tydeleg formål
• avklarte roller
• intern policy
• prosess for varsling og handsaming
• lokal juridisk vurdering

Teknologien kan redusere risiko. Ho kan ikkje ta den vurderinga for deg.

Start med få signal, ikkje alle signal

For dei fleste norske verksemder er den beste starten ikkje å skru på alt. Det gir mest støy, mest intern uro og minst læring.

Ein betre start er å prioritere 2–3 konkrete scenario:

1. Dataeksfiltrering frå vanlege samarbeidsflater
   Start med data leaks, men berre dersom de faktisk har DLP-policyar som er verd noko.

2. Avgang eller rolleendring
   Departing users kan vere nyttig dersom offboarding er eit reelt problemområde og HR-prosessane er modne nok.

3. Mistenkjeleg bruk kombinert med tryggingssignal
   Security policy violations er interessant når Defender for Endpoint allereie er i drift og de faktisk jobbar med hendingar på tvers av sikkerheit og compliance.

Det viktige er å velje scenario de kan følgje opp operativt, ikkje scenario som ser bra ut i ei PowerPoint.

Kven bør eige dette?

I mange miljø hamnar Purview i eit tomrom mellom IT-drift, sikkerheit, compliance og HR. Det er ein dårleg idé for Insider Risk Management.

Du bør minst avklare:

• kven som får sjå alertar
• kven som får opprette og handtere saker
• kven som kan deanonymisere brukarar
• når HR eller leiing skal involverast
• når ei sak skal løftast til eDiscovery eller annan formell gransking

Microsoft dokumenterer koplingar mot både eDiscovery (Premium), Defender-relaterte signal og andre integrasjonar, men det gjer berre rollestyring viktigare, ikkje mindre viktig.

Create and manage Insider Risk Management policies

Dokumentasjon for policyadministrasjon, prioritering og korleis signal og innhald blir brukte i IRM.

Kva med SMB: er dette verd kostnaden?

Det korte svaret er: av og til.

Det lengre svaret er at mange mindre verksemder ikkje treng full breidde i Purview. Dei treng nok til å:

• redusere risiko for feil deling og eksfiltrering
• få betre signal når ein konto blir brukt unormalt
• binde saman identitet, data og aktivitet
• ha ein kontrollmodell for Copilot og annan KI-bruk

Dersom de manglar grunnmuren, til dømes klassifisering, DLP, rollemodell og enkel governance , vil IRM fort bli eit dyrt lag med støy oppå eit rotete fundament.

Så vurder kost/nytte brutalt ærleg:

• Har de faktiske datasett de er redde for?
• Har de folk som kan følgje opp alertar?
• Har de DLP eller labels som allereie betyr noko?
• Har de eit reelt behov for gransking og sporbarheit?

Viss svaret er nei på alt dette, start ein annan stad først.

Insider risk og KI: no heng det saman

I 2026 gir det lite meining å diskutere insider risk utan å snakke om Copilot og KI-governance.

Microsoft viser Purview-kontrollar for Microsoft 365 Copilot og Copilot Chat i samanheng med DLP, sensitivity labels, DSPM og Insider Risk Management.

Use Microsoft Purview to manage data security & compliance for Microsoft 365 Copilot & Microsoft 365 Copilot Chat

Microsoft si oversikt over korleis Purview blir brukt for datatryggleik og compliance rundt Copilot.

Learn about Data Security Posture Management

Dokumentasjon for DSPM og objective-baserte arbeidsflytar som samlar relevante Purview-kontrollar.

Det betyr ikkje at IRM magisk løyser KI-risiko. Det betyr at du no må sjå desse kontrollane samla:

• Kva data kan Copilot nå?
• Kva er klassifisert?
• Kva blir stoppa av DLP?
• Kva blir oppdaga som risikabel bruk?
• Kven eig oppfølginga?

Det er her mange verksemder kjem til å feile: Dei behandlar Copilot som produktivitet, DLP som compliance og insider risk som HR/sikkerheit. I røynda er dette same styringsproblem.

Ein praktisk startguide

Viss du vil teste om IRM er relevant i di verksemd, ville eg gjort dette i denne rekkjefølgja:

1. Avklar formål
   Kva prøver de faktisk å oppdage: datalekkasjar, dårleg offboarding, mistenkjeleg bruk eller policybrot?

2. Sjekk lisens og region
   Ikkje start med design før de veit at tenesta og avhengigheitene faktisk er støtta for miljøet dykkar.

3. Definer roller og personvernmodell
   Kven skal sjå kva? Kven kan deanonymisere? Kven skal godkjenne gransking?

4. Start med eitt eller to scenario
   Ikkje meir.

5. Kople på dei signala som faktisk har kvalitet
   DLP, Defender for Endpoint, HR-data eller andre signal berre dersom de stolar på dei.

6. Køyr tuning før de gjer dette til drift
   Støy er den raskaste måten å miste tillit til heile opplegget på.

7. Knytt dette til KI-governance
   Viss de brukar Copilot, må datakontrollane og insider-risk-vurderingane sjåast samla.

Kva du ikkje bør gjere

Nokre klassiske feil:

• skru på fleire templatear enn de kan handtere
• gi for brei tilgang til alertar og saker
• importere HR-data utan avklart formål
• tru at pseudonymisering fjernar juridisk ansvar
• sjå IRM isolert frå DLP, labels og identitet
• bruke løysinga som generell medarbeidarovervaking

Den siste er særleg viktig. Viss verksemda ikkje klarer å forklare kvifor dette finst, og kva som er rammene, har de eit governance-problem før de har eit teknisk problem.

Heilt ærleg?

Insider Risk Management er viktigare i 2026 enn namnet tilseier.

Ikkje fordi alle verksemder har illojale tilsette, men fordi kompromitterte kontoar, feil bruk av data og KI-dreven informasjonsflyt gjer at «intern» og «ekstern» risiko glir over i kvarandre.

For norske verksemder er den reelle verdien ikkje å overvake folk meir. Han ligg i å binde saman identitet, data, signal og oppfølging på ein måte som faktisk fangar opp risiko når angriparen ser ut som ein vanleg brukar.

Men berre dersom de startar smalt, styrer stramt og held personvern og arbeidsrett like høgt som teknologien.