Alle gjør risikoanalyser. Få gjør dem riktig.
Risikoanalyse er hjørnesteinen i digitalsikkerhetsloven, ISO 27001 og i prinsippet alle sikkerhetsrammeverk som finnes. Alle vet at det skal gjøres. Men etter å ha sett hundrevis av risikomatriser kan jeg konstatere: de fleste gir et nøyaktig bilde av helt feil ting.
Problemet er ikke at organisasjoner hopper over risikoanalysen. Problemet er at de gjør den på en måte som ikke gir reelt beslutningsgrunnlag. Resultatet blir et dokument som ser profesjonelt ut i en perm, men som aldri påvirker en eneste beslutning.
Her er de fem vanligste feilene — og hvordan du unngår dem.
Feil 1: Kopiere andres risikoregistre
Det er fristende å begynne med en mal. Noen andres risikoregister, en bransjestandards eksempelrisikoer, eller et konsulentselskaps forhåndsdefinerte liste. Problemet? Andres risikoer er ikke deres risikoer.
En produksjonsorganisasjon og en SaaS-leverandør har fundamentalt forskjellige risikolandskap. Selv innenfor samme bransje varierer risikoene avhengig av størrelse, IT-miljø, kundestruktur og modenhet.
Riktig tilnærming: Begynn med deres egne informasjonsflyter. Hvilken informasjon håndterer dere? Hvor lagres den? Hvem har tilgang? Hvilke prosesser er avhengige av den? Deres risikoer oppstår i gapet mellom informasjonens verdi og de truslene som kan utnytte sårbarheter i hvordan dere håndterer den.
Feil 2: Blande iboende risiko og kontrolleffektivitet
Dette er den mest utbredte feilen. Organisasjonen vurderer en risiko som “lav” — men den er bare lav fordi det allerede finnes en kontroll på plass. Hva skjer hvis kontrollen slutter å fungere? Hvis brannmurregelen endres, hvis backup-tjenesten opphører, hvis den erfarne medarbeideren slutter?
Når iboende risiko og kontrolleffektivitet blandes i samme vurdering, mister dere evnen til å forstå hva kontrollene faktisk bidrar med. Dere ser ikke hvor dere er mest sårbare hvis en kontroll svikter.
Separer alltid vurderingen i to trinn:
- Iboende risiko — Hvor alvorlig er risikoen uten kontroller? Dette gir dere et bilde av den underliggende trusselen.
- Kontrolleffektivitet — Hvor godt reduserer eksisterende kontroller risikoen? Dette viser hvor investeringene deres faktisk gjør en forskjell.
Forskjellen gir dere gjenværende risiko — risikoen dere faktisk lever med i dag. Det er denne som skal sammenlignes med deres risikoappetitt.
Feil 3: Falsk presisjon med flerdimensjonale skalaer
En 5×5-matrise med sannsynlighet og konsekvens gir 25 mulige nivåer. Det ser nøyaktig ut. Men hvis vurderingene ikke kan skille mellom “sannsynlighet 3” og “sannsynlighet 4” på en konsistent måte, har dere bare lagt til støy til analysen.
Verre: mange organisasjoner bruker skalaer hvor dimensjonene ikke er uavhengige. “Høy sannsynlighet og høy konsekvens” blir automatisk “kritisk risiko” — men hva hvis sannsynligheten er høy nettopp fordi konsekvensen er lav (og organisasjonen derfor ikke har prioritert beskyttelse)?
Hva som fungerer bedre:
- Bruk færre nivåer (3×3 holder ofte)
- Definer hvert nivå med konkrete eksempler relevante for deres virksomhet
- Kalibrer ved å vurdere en rekke risikoer sammen før dere kjører individuelt
- Aksepter at risikovurdering er en kvalifisert vurdering, ikke en eksakt vitenskap
Feil 4: Risiko uten kobling til forretningspåvirkning
“Risikoen for uautorisert tilgang til systemet vurderes som middels høy.” Utmerket. Og hva betyr det for virksomheten? Ingenting, hvis vurderingen stopper der.
Styret vil ikke høre sannsynlighetsnivåer. De vil vite: hva koster det hvis det skjer? Hvor lenge ligger vi nede? Hvilke kunder påvirkes? Hvilke regulatoriske konsekvenser utløses?
Koblingen mellom teknisk risiko og forretningspåvirkning er det som gjør risikoanalysen til et beslutningsgrunnlag i stedet for et IT-dokument.
| Teknisk vurdering | Forretningsspråk |
|---|---|
| ”Høy sannsynlighet for ransomware" | "30% risiko for 5 dagers produksjonsstopp, estimert kostnad 3–8 MNOK" |
| "Middels risiko for datalekkasje" | "Potensiell GDPR-bot og tap av 2–3 nøkkelkunder" |
| "Lav risiko for DDoS" | "Maks 4 timers nedetid, begrenset forretningspåvirkning” |
Feil 5: Engangsøvelse i stedet for levende prosess
Den vanligste tidspunktet for en risikoanalyse? Rett før en revisjon, sertifisering eller tilsynskontroll. Så legges den i en mappe til neste gang.
En risikoanalyse som ikke er oppdatert siden den ble gjort, reflekterer et trussellandskap som ikke lenger eksisterer. Nye systemer innføres, leverandører skiftes ut, trusselaktører endrer taktikk, organisasjonen omstruktureres. En statisk risikoanalyse er som en værmelding fra forrige måned — den var korrekt da den ble laget, men den styrer ingen beslutninger i dag.
Nye systemer, leverandører, prosesser eller organisasjonsendringer skal utløse en revurdering av berørte risikoer. Det trenger ikke være en fullstendig omgjøring — fokuser på det som har endret seg.
Minst årlig bør hele risikoregisteret gjennomgås. Kvartalsvise gjennomganger av de høyest prioriterte risikoene gir enda bedre styring.
Hver hendelse bør føre til en revurdering av relevante risikoer. Hendelser gir dere faktiske data om trussellandskapet — bruk dem.
Et risikoregister som bare risikoanalytikeren kan tolke driver ingen beslutninger. Gjør det forståelig for de som fatter beslutningene — ledelsen.
Risikoanalyse som driver beslutninger
En risikomatrise er ikke et mål i seg selv. Den er et verktøy for å fatte bedre beslutninger om hvor organisasjonen skal legge sine begrensede ressurser. Hvis deres risikoanalyse ikke endrer prioriteringer, ikke påvirker budsjettbeslutninger og ikke diskuteres på ledelsesnivå — da tjener den ikke noe formål.
Spør dere: når var siste gang et resultat fra risikoanalysen faktisk førte til en endring? Hvis svaret er “aldri” eller “jeg vet ikke” — da er det på tide å revurdere ikke bare risikoene, men prosessen.
Securapilots risikomodul bygger på ISO 27005 og separerer iboende risiko fra kontrollvurdering — slik at deres risikobilde faktisk gjenspeiler virkeligheten og gir dere det beslutningsgrunnlaget dere trenger.
Ofte stilte spørsmål
Hvorfor fungerer ikke risikomatriser?
Risikomatriser kan fungere — hvis de brukes riktig. Problemene oppstår når organisasjoner kopierer generiske risikoregistre, blander sammen risikonivåer med kontrollstatus, eller aldri oppdaterer vurderingen. En risikomatrise skal gi beslutningsgrunnlag, ikke bare et fargekodete bilde.
Hva er forskjellen mellom iboende risiko og gjenværende risiko?
Iboende risiko er risikonivået før kontroller anvendes. Gjenværende risiko er den risikoen som gjenstår etter at kontroller er implementert. Å separere disse gir et tydelig bilde av hvilke kontroller som faktisk gjør en forskjell.
Hvor ofte skal risikoanalysen oppdateres?
Minst årlig, men også ved vesentlige endringer i virksomheten, IT-miljøet eller trusselbildet. En risikoanalyse som ikke er oppdatert på over et år gjenspeiler sannsynligvis ikke virkeligheten.
Hvordan kobler man risikoanalyse til forretningsbeslutninger?
Uttrykk risikoer i termer styret forstår: potensiell økonomisk påvirkning, driftsavbrudd i timer/dager, og regulatoriske konsekvenser. Unngå teknisk sjargong og sannsynlighetsprosent uten kontekst.
