NIS2 gør noget ret typisk for regulering: den siger “I skal have styr på risici” uden at give dig en magisk knap, der gør det nemt. Resultatet bliver ofte, at virksomheder enten drukner i excel-ark og kontrolkataloger, eller også laver de en pæn powerpoint, der ikke ændrer noget i hverdagen.
Denne artikel giver dig en praktisk, brugbar model til risikostyring under NIS2, så du kan prioritere de rigtige tiltag i den rigtige rækkefølge, uden at bygge et bureaukrati, der selv bliver en risiko.
Hvad NIS2 i praksis kræver af risikostyring
NIS2 handler ikke om at have “alle kontroller”. Den handler om at have passende og proportionelle sikkerhedsforanstaltninger baseret på risiko, samt at kunne dokumentere hvordan du arbejder med det.
Det betyder i praksis:
- Du skal kunne forklare hvilke risici der er vigtigst for jeres forretning.
- Du skal kunne vise hvilke tiltag I har valgt, og hvorfor.
- Du skal kunne vise, at det ikke er en engangsøvelse, men en løbende proces.
Den praktiske model: 6 trin fra kaos til prioriteret plan
Her er modellen, som fungerer i virkeligheden (ikke kun i compliance-land):
- Afgræns scope og “hvad der betyder noget”
- Kortlæg aktiver og afhængigheder
- Byg 10-15 realistiske risikoscenarier
- Scor risiko med simple kriterier
- Map til tiltag og prioriter “mest effekt først”
- Lav en 30/60/90-dages plan + governance
Lad os tage dem i rækkefølge.
Trin 1: Afgræns scope, så du ikke risikostyrer hele universet
Risikostyring fejler ofte, fordi scope bliver:
- “alt IT”
- “alt i virksomheden”
- “alt vores leverandører gør”
Det er en sikker vej til at lave et dokument, ingen bruger.
Start med at definere:
- Kritiske services/processer (hvad må ikke stoppe?)
- Kritiske systemer (hvad understøtter de services?)
- Kritiske data (hvad kan ikke lække eller gå tabt?)
En god tommelfingerregel: Hvis det ikke påvirker drift, kunder, økonomi eller lovkrav væsentligt, så er det ikke første prioritet.
Trin 2: Kortlæg aktiver og afhængigheder (hurtigt og brutalt)
Du behøver ikke en perfekt CMDB for at starte. Du skal bare have et troværdigt overblik over:
- Kerneapplikationer (ERP, CRM, e-mail, kundevendte platforme)
- Infrastruktur (cloud, netværk, endpoints, identitet)
- Dataflows (hvor løber data hen, og hvem har adgang?)
- Leverandører (drift, SaaS, MSP, sikkerhedsleverandører)
Lav det simpelt:
- 1 linje pr. aktiv
- ejer (hvem kan tage beslutninger?)
- hvilken service afhænger af det?
- “single point of failure?” ja/nej
Det er nok til at komme videre.
Trin 3: Formulér 10-15 risikoscenarier (det er her magien sker)
I stedet for at score 200 kontroller, scorer du scenarier, fx:
- Phishing fører til konto-overtagelse og dataudtræk
- Ransomware krypterer filserver/SharePoint og stopper drift
- Leverandørnedbrud (SaaS/MSP) stopper kritisk proces
- Fejl i adgangsstyring giver for brede rettigheder
- Manglende logning gør, at et angreb opdages for sent
- Backup kan ikke gendannes indenfor acceptable tider
- Uautoriserede ændringer i cloud-konfiguration åbner for datalæk
- DDoS mod kundevendt løsning (hvis relevant)
- Insider-fejl (ikke “ondsindet insider”, bare menneskelige fejl)
Scenarier gør to ting:
- De gør risiko konkret og forståelig for ledelsen
- De gør prioritering mulig, fordi du kan se “hvad gør mest skade”
Trin 4: Scor risiko simpelt: Impact × Likelihood (og ét ekstra felt)
Hold det på en skala 1-5. Ikke fordi det er videnskab, men fordi det er brugbart.
Impact (1-5) kan vurderes ud fra:
- Driftstop (hvor længe kan I være nede?)
- Økonomi (omsætning/tab)
- Data (læk/tab)
- Omdømme (kunder/medier)
- Lov/kontrakter (krav, bod, konsekvens)
Likelihood (1-5) ud fra:
- Hvor ofte sker det i jeres branche?
- Hvor let er det at udnytte?
- Hvor moden er jeres nuværende sikkerhed?
Ekstra felt: “Detektionstid” (1-5)
Det er undervurderet. Hvis I først opdager problemer efter 30 dage, bliver alt dyrere. Detektionstid hjælper dig med at prioritere logning, alarmer og response.
Så kan du lave en samlet score, fx:
- Risiko-score = Impact × Likelihood
- “Boost” hvis detektionstid er dårlig (fx +20% eller en ekstra prioriteringsflag)
Trin 5: Map risiko til tiltag og prioriter “størst risikoreduktion pr. indsats”
Nu tager du hvert scenarie og spørger:
- Hvad reducerer sandsynlighed?
- Hvad reducerer konsekvens?
- Hvad forbedrer detektion og respons?
Eksempel:
Scenarie: Phishing → konto-overtagelse
- MFA overalt (især admin og fjernadgang)
- Conditional access / device compliance
- Sikker mail gateway + awareness (målrettet, ikke “årlig quiz”)
- Privileged Access Management (hvis muligt)
- Logning/alarmer på umulige login, OAuth-consent, MFA fatigue
Scenarie: Ransomware → driftstop
- Offline/immutables backups + restore-test
- Segmentering og least privilege
- EDR på endpoints
- Patch management
- Incident response playbook
Prioriteringsmatrice: Effekt vs. indsats
Lav en 2×2:
- Høj effekt / lav indsats: Gør nu (quick wins)
- Høj effekt / høj indsats: Planlæg og ressource-sæt
- Lav effekt / lav indsats: Fyld ind senere
- Lav effekt / høj indsats: Overvej om det overhovedet er værd at gøre
Det er her du undgår at bruge 3 måneder på en kontrol, der næsten ikke rykker risikoen.
Trin 6: Gør det operationelt: 30/60/90 dage + governance
Risikostyring er kun nyttig, hvis den ender som:
- beslutninger
- opgaver
- deadlines
- ejerskab
30 dage (stabilisér og luk de værste huller)
- MFA/conditional access på kritiske konti
- Backup-restore test (rigtigt, ikke “vi tror det virker”)
- Grundlæggende patching-rytme
- Basis logning og alarmer på kerneevents
- Identificér top 5 leverandørrisici og få styr på kontrakt/ansvar
60 dage (byg fundament og drift)
- Least privilege og rollebaseret adgang
- EDR og central device management
- Incident response: hvem gør hvad hvornår (og kontaktliste)
- Sårbarhedsoverblik og prioritering
- Leverandørstyring: krav, review, kontaktpunkter, SLA for hændelser
90 dage (modenhed og dokumentation)
- Målepunkter (MTTD/MTTR, patch compliance, backup success)
- Tabletop-øvelse (simuler et angreb)
- Proces for ændringsstyring og sikker konfiguration (cloud inkluderet)
- Formaliseret risikoregister og kvartalsvis review
Dokumentationen: det du skal kunne vise, uden at bygge et papirslot
Hold dokumentation let, men brugbar:
- Risikoregister (scenarie, score, beslutning, tiltag, ejer, deadline)
- Tiltagsplan/roadmap (30/60/90 + kvartalsplan)
- Politikker light (adgang, backup, logging, incident response)
- Leverandøroversigt (kritikalitet, afhængighed, kontakt, krav)
- Beviser (screenshots/udtræk): MFA slået til, backup test log, patch rapport osv.
Hvis du vil have en samlet indgang til, hvordan man griber arbejdet an uden at drukne i teori, kan du tage udgangspunkt her: risikostyring til NIS2
Typiske fejl (som mennesker elsker at gentage)
- At starte med kontrolkataloger i stedet for scenarier
Du ender med tjekbokse uden prioritering. - At score alt lige vigtigt
Så er intet vigtigt, og planen dør. - At overse leverandører
NIS2 handler også om supply chain. Hvis I er afhængige af en MSP/SaaS, skal det med. - At glemme detektion og respons
Forebyggelse fejler. Det gør det altid. Spørgsmålet er hvor hurtigt I opdager det, og hvor hurtigt I stopper det.
Konklusion
Risikostyring under NIS2 behøver ikke være et kæmpe compliance-projekt. Hvis du arbejder scenarie-baseret, scorer simpelt, og prioriterer ud fra effekt vs. indsats, kan du få en plan, der både giver reel sikkerhed og troværdig dokumentation.
Målet er ikke at “gøre alt”. Målet er at gøre det rigtige først, og kunne vise hvorfor. Det er kedeligt. Det virker.
